*  CMU-CS-81- 113 


CD 
^ ; 

o 

rH 

< 

Q 

Mechanical  Transformation 
of 

Task  Heuristics 
into 

Operational  Procedures 

Ph.D.  Thesis 

David  J.  Mostow 
Computer  Science  Department 
Camegie-Mellon  University 

)4  April  1981 


£ 


UJ 


DEPARTMENT 

of 

COMPUTER  SCIENCE 


Iml 


'A 


Carnegie-Mellon  University 

81  9  2  8  1  67 


/  CMU-CS-81-113 


/£) 


\  j  L  ^ 1  N  '<-• 


MechanicalJ  ransformation 

Task  JJeuristics 
^  into 

OperationaTProcedures  • 


PhD.  Thesis 


-VWt.d  /gj 

David  J.  Mostow 
Computer  Science  Department 
Carnegie- Mellon  University 


April  081 


%  F 23T^S-  C-  J&sJ) 

x/u  d^cUb- 3^91  f 


^  &  * ; 


**  9  vn^  ' 


Copyright  ©  1981  by  David  J.  Mostow 


This  research  was  sponsored  in  part  by  a  National  Science  Foundation  Graduate  Fellowship,  in  part 
by  the  National  Science  Foundation  under  grant  no.  MCS77-03273  to  the  Rand  Corporation,  and  in 
part  by  the  Defense  Advanced  Research  Projects  Agency  (DOD),  ARP  A  Order  No.  3597,  monitored 
by  the  Air  Force  Avionics  Laboratory  Under  Contract  F33615-78-C-1551. 

The  views  and  conclusions  contained  in  this  document  are  those  of  the  author  and  should  not  be 
interpreted  as  representing  the  official  policies,  either  expressed  or  implied,  of  the  National  Science 
Foundation,  the  Rand  Corporation,  the  Defense  Advanced  Research  Projects  Agency,  or  the  US 
Government. 


fk£. 

In-' 


Abstract 


Advice  about  how  to  perform  a  task  can  often  be  expressed  in  the  language  of  the  task  domain  quite 
simply.  For  example,  advice  for  how  to  play  the  card  game  Hearts  includes  “avoid  taking  a  tnck  with 
points,”  “try  to  flush  out  the  Queen  of  spades.”  and  “don't  lead  a  high  card  in  a  suit  where  an 
opponent  is  void.”  However,  such  advice  is  not  operational  because  it  is  not  expressed  in  terms  of  the 
basic  capabilities  of  the  task  agent  --  it  doesn't  tell  what  card  to  play  next.  Developing  a  procedure  to 
implement  the  advice  (“operationalizing"  the  advice)  can  be  difficult  due  to  limitations  imposed  by 
the  structure  of  the  task  and  the  environment  in  which  the  task  is  performed.  Advice  may 
recommend  an  action  that  cannot  be  directly  executed  --  a  Hearts  player  cannot  flush  the  Queen  by 
snatching  it  from  an  opponent's  hand.  Advice  may  be  expressed  m  terms  of  unobservable 
information  -  a  Hearts  player  cannot  peek  at  opponents'  cards  to  see  who's  void,  or  look  into  the 
future  to  find  out  if  a  trick  will  have  points. 

. 

This  dissertation  characterizes  the  operationalization  of  advice  as  a  series  of  problem  transformations 
leading  from  the  advice  statement  to  a  procedure  for  achieving  a  specified  goal  (avoid  taking  points) 
or  evaluating  a  specified  quantity  (decide  whether  an  opponent  is  void).  It  describes  some  general 
operators  for  performing  such  transformations.  These  operators  have  been  implemented  in  a 
program  called  POO  as  domain-independent  transformation  rules  that  access  a  knowledge  base  of  task 
domain  concepts.  They  have  been  used  to  operauonalize  advice  for  the  card  game  Hearts  and  a 
music  composition  task.  Some  of  FOO's  transformation  rules  represent  high-level  strategies  tor 
operationalizing  advice.  Additional  rules  represent  reasoning  methods  used  to  reformulate  advice  in 
terms  of  these  operationalization  strategies,  solve  the  subproblems  they  generate,  and  translate  their 
results  into  a  usable  form.  Although  POO  lacks  a  problem-solving  component  for  choosing  which  of 
these  transformation  rules  to  apply,  the  dissertation  shows  how  means-end  analysis  could  be  used  to 
guide  the  search  through  the  problem  space. 

The  dissertation  formalizes  the  notion  of  reformulating  one  concept  in  terms  of  another,  for  example, 
reformulating  “take  points”  in  terms  of  “playing  the  highest  card  in  the  suit  led.  It  describes 
mechanical  techniques  for  mapping  domain-specific  problems  onto  general  methods.  In  particular,  it 
examines  in  detail  the  process  of  formulating  a  problem  as  a  heuristic  search,  and  presents  domain- 
independent  rules  that  improve  a  search  procedure  by  deriving  new  heuristics  based  on  analysis  of 
the  problem  and  knowledge  about  the  task  domain. 
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Preface 


Papers  and  talks  in  artifical  intelligence  tend  to  include  buzzwords  and  “motherhood  statements” 
about  blackboard  organizations,  knowledge  sources,  hierarchical  levels  of  representation,  multiple 
perspectives,  and  so  forth.  This  phenomenon  is  by  no  means  limited  to  AJ:  it  characterizes  other 
areas  of  computer  science  as  well,  and  no  doubt  numerous  other  fields.  Short  research  presentations 
all  too  often  contain  nothing  else,  and  provide  examples  of  content-free  language. 

The  spectacle  of  an  uninformative  presentation  made  by  an  intelligent  researcher  poses  a  genuine 
paradox.  One  explanation  for  this  paradox  is  that  the  real  problem  involved  in  most  Al  research  is  to 
take  an  existing,  more-or-lcss  self-evident  (or  at  least  widely  accepted  as  plausible)  approach  and 
operationalize  it  for  a  particular  task.  For  example,  one  might  use  the  blackboard  model  to 
understand  speech  [Erman  75),  decode  proteins  [Engelmore  79],  or  learn  the  rules  of 
baseball  [Soloway  77]1.  However,  the  real  content  of  such  an  effort  lies  in  figuring  out  how  to  make 
the  general  paradigm  operational  in  the  context  of  the  particular  problem: 

What  are  the  sources  of  knowledge? 

How  should  this  knowledge  be  represented? 

What  language  should  the  knowledge  sources  communicate  in? 

How  should  their  interactions  be  organized? 

What  policies  should  govern  the  allocation  of  computational  resources,  and  what  mechanisms 

should  be  used  to  implement  them? 

How  should  tire  problem  be  defined,  and  how  should  a  potential  solution  be  evaluated? 

These  are  the  hard  problems  of  research,  the  kind  that  often  lie  just  below  the  level  at  which  the 
research  is  reported  because  their  solutions  arc  difficult  to  communicate.  This  train  of  drought  leads 
to  the  provocative  assertion  that 

Operationalization  is  the  real  content  of  most  A I  research. 


1Th  e  use  of  these  projects  as  examples  is  not  meant  10  reflect  in  any  way  on  tire  presentational  skills  of  their  authors. 
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This  assertion  can  be  broadened  to  include  a  considerable  proportion  of  scientific  research,  or  even 
intelligent  behavior  in  general;  however,  it  applies  with  special  force  to  computer  science,  since  this 
field  is  to  such  a  great  extent  a  study  of  methods.  It  is  illustrated  by  the  fact  that  most  of  the 
dissertation  research  reported  here  was  directed  at  operationalizing  the  concept  of  operationalization. 
The  assertion  implies  that 

Real  progress  in  automating  the  construction  of  intelligent  programs  will  ultimately  require 
a  thorough  understanding  of  operationalization. 

This  dissertation  is  one  step  toward  that  goal. 
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Chapter  1 
Introduction 

A  central  theme  of  recent  research  in  artificial  intelligence  is  that 

Intelligent  task  performance  requires  large  amounts  of  knowledge  about  the  task  domain. 

A  major  bottleneck  in  building  a  program  to  perform  an  intelligent  task  lies  in  converting 
knowledge  into  a  form  readily  applicable  to  the  task  by  a  relatively  simple  runtime  mechanism,  such 
as  an  EVAL  routine  for  LISP  procedures  [McCarthy  63],  an  interpreter  for  condition-action 
productions  [Davis  76],  or  a  back-chaining  inference  engine  for  MYCIN-stylc  rules  [Davis  77a]. 

Machine-aided  heuristic  programming  [Haycs-Roth  78a]  is  a  proposed  approach  for  facilitating  the 
translation  of  domain  knowledge  into  task  performance.  The  idea  is  to  instruct  a  computer  to  do  a 
new  task  in  much  the  same  way  one  would  instruct  a  person:  by  giving  an  informal  description  of  the 
task  plus  some  advice  for  how  to  do  it  well.  For  example,  if  the  task  is  to  play  the  card  game  Hearts 
(described  in  Appendix  A.l),  the  task  description  would  include  the  rules  of  the  game,  and  the  advice 
would  include  heuristics  like: 

"Avoid  taking  points." 

"Don’t  lead  a  high  card  in  a  suit  in  which  an  opponent  is  void.” 

“If  an  opponent  has  the  Queen  of  spades,  try  to  flush  it.” 

If  the  task  is  to  compose  a  cantus  firmus  (q.v.  Appendix  A.2),  the  basic  description  would  be 
"generate  a  series  of  musical  tones  of  equal  length,”  and  the  advice  would  include  heuristics  like 
these  (taken  from  a  textbook  on  counterpoint): 

"The  cantus  should  include  an  unrcpcatcd  climax.” 

"The  melodic  range  of  the  cantus  should  not  exceed  a  major  tenth.” 

Since  these  descriptions  are  expressed  in  terms  specific  to  the  respective  task  domains  of  Hearts 
and  music,  rather  than  in  the  vocabulary  of  programming  languages,  it  would  also  be  necessary  to 
provide  the  computer  with  definitions  of  these  terms,  e.g.: 
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“Being  void  in  a  suit  means  having  no  cards  in  that  suit” 

"Flushing  a  card  means  forcing  whoever  has  it  to  play  it.” 

“The  melodic  range  of  a  tone  sequence  is  the  interval  between  its  lowest  and  highest  notes.” 

Converting  this  kind  of  task  description  into  effective  behavior  involves  several  processes.  The 
informal  natural  language  description  must  be  encoded  into  a  precise  representation  of  its  meaning 
better  suited  to  mechanical  manipulation.  It  must  be  operationalized  in  terms  of  primitive 
capabilities.  Different  pieces  of  advice  must  be  integrated.  The  knowledge  must  be  applied  to 
specific  task  situations  at  runtime. 

This  paradigm  avoids  re-operationalizing  the  task  description  for  each  new  task  situation;  rather,  it 
converts  the  task  description  into  an  operational  form  that  is  general  enough  to  be  applied  to 
different  task  situations.  One  reason  for  this  is  efficiency.  If  operationalization  is  computationally 
expensive,  performing  it  repeatedly  for  a  frequently  performed  task  is  intolerable.  Another  reason  is 
timeliness.  Applying  advice  to  a  task  situation  can  require  some  advance  preparation.  For  example, 
consider  the  advice 

“Don’t  lead  a  high  card  in  a  suit  in  which  an  opponent  has  shown  void.” 

This  advice  bears  on  the  decision  of  what  card  to  lead,  but  it  requires  remembering  who  has  shown 
void  in  what  suit  A  human  can  try  to  rely  on  serendipity  or  on  total  recall  for  remembering  such 
information,  but  a  more  practical  approach  for  a  computer  program  with  limited  memory  is  to 
operationalize  the  advice  ahead  of  time  and  decide  to  remember  who  shows  void  in  what  suit 

1.1.  Problem  Definition 

This  dissertation  focusses  on  the  problem  of  transforming  advice  into  an  operational  form,  ie..  a 
procedure  that  can  be  applied  to  the  task  at  hand: 

A  procedure  is  a  (relatively)  operational  form  of  a  piece  of  advice  if  the  agent  performing  the 
task  can  apply  the  procedure  in  (many  of)  the  situations  where  the  advice  is  relevant,  and  the 
result  of  doing  so  is  (often)  consistent  with  the  advice. 

Thus  operationaiity  is  a  relation  between  a  piece  of  advice,  the  agent  for  whom  the  advice  is 
intended,  and  a  procedure  executed  by  the  agent  to  implement  the  advice.  Whether  such  a 
procedure  is  operational  may  depend  on  the  actions  the  agent  can  perform  in  the  task  environment, 
the  information  the  agent  can  obtain  by  direct  observation,  and  the  computations  the  agent  can  make 
based  on  that  information. 
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1.1.1.  Model  of  a  Task  Agent 

This  view  is  based  on  a  model  in  which  an  agent’s  interactions  with  a  task  environment  are 
restricted  to  a  channel  defined  by  the  agent’s  capabilities  for  observation  and  action,  as  shown  in 
Figure  1-1. 


< —  store  —  —  function  arguments  --> 

MEMORY  TASK  AGENT  COMPUTATION 

—  recall  — >  < -  function  value  - 


sensory  effector 
operations  operations 

I  ! 

I  v 

TASK  ENVIRONMENT 

Figure  1-1:  Model  of  a  task  agent 

Sensory  operations  obtain  information  by  direct  observation  of  the  task  environment.  The  agent’s 
sensory  capabilities  can  be  modelled  by  a  collection  of  functions  fv  ....  fn  whose  domain  is  the  space 
of  task  situations,  or  states.  The  agent  knows  f^s), ....  fn(s)  in  any  state  s,  and  this  information  covers 
everything  it  can  directly  observe  about  s.  Each  such  function  will  be  called  observable.  For  example, 
in  Hearts  one  can  observe  one’s  hand  and  the  cards  in  the  pot.  Note  that  the  agent  has  no  direct 
access  to  the  "value”  of  the  situational  variable  s,  which  denotes  the  entire  state  of  the  environment  at 
a  given  time.  In  FOO,  the  operationalization  program  to  be  described  later,  this  variable  is  not 
referred  to  explicitly;  instead,  state-dependent  expressions  like  (CARDS-in-pot)  (“the  cards  in  the 
pot”)  and  (HAS  ME  Cl )  (“player  ME  has  card  Cl”)  are  implicit  functions  of  s. 

The  other  direction  along  the  channel  between  agent  and  task  environment  consists  of  effector 
operations  -  the  agent’s  capabilities  for  performing  actions  that  change  the  state  of  the  task 
environment.  The  actions  in  Hearts  include  playing  a  card  (from  one’s  hand  to  the  pot)  and  taking  a 
card  (from  the  pot  to  one's  pile).  Such  an  operation  can  be  modelled  by  a  function  f  from  suites  to 
states,  where  ffs)  is  the  state  that  results  from  performing  the  operation  f  in  state  s.  Such  a  function 
will  be  called  doable  if  it  corresponds  to  an  action  the  agent  can  perform.  The  function  is  only 
defined  on  those  states  in  which  the  agent  can  perform  the  action.  Similar  functions  may  represent 
actions  that  other  agents  in  the  environment  can  perform,  but  these  arc  not  (directly)  doable.  Thus 
the  action  (PLAY  ME  QS)  (“player  ME  plays  the  Queen  of  spades”)  is  doable  whenever  player  ME  (the 
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agent)  can  legally  play  the  Queen  of  spades,  but  the  action  (PLAY  PI  QS)  is  not  doable  for  PI  *  ME, 
since  the  actions  of  player  PI  are  not  under  player  MB’s  direct  control. 

In  addition  to  sensory  and  effector  operations,  which  comprise  the  two  directions  of  the  channel 
between  agent  and  environment,  the  agent  has  purely  internal  capabilities.  One  of  these  is 
computation :  the  agent  can  calculate  the  values  of  various  functions  given  their  arguments.  Such 
functions  will  be  called  computable.  Another  capability  is  (unlimited)  memory:  in  principle,  the 
agent  has  access  to  any  past  observation  or  computation.  (This  capability  can  be  implemented 
without  prohibitive  storage  costs  if  it  is  known  a  priori  what  information  will  be  needed  later  (§2.4).) 

The  class  of  evaluable  state-dependent  functions  in  this  model  can  be  recursively  defined: 

1.  Direct  observation:  Any  observable  function  f  is  evaluable. 

2.  Computation:  If  f  is  evaluable  and  g  is  computable,  then  g  o  f  is  evaluable. 

3.  Memory:  If  f  is  evaluable,  then  the  value  f  that  f  had  at  a  past  time  t  is  evaluable. 

This  paradigm  incorporates  several  simplifications: 

1.  The  model  does  not  specify  computational  costs,  although  such  costs  can  certainly  affect  the 
feasibility  of  evaluating  a  given  expression. 

2.  Memory  processes  for  storage  and  retrieval  are  treated  implicitly  rather  than  explicitly  ;  there  is 
no  concept  of  a  data  structure  and  operations  on  it 

3.  The  agent's  “state  of  mind”  is  not  part  of  the  task  environment;  otherwise,  the  distinction 
between  sensory  and  state-changing  operations  would  break  down,  since  the  act  of  making  an 
observation  affects  the  agent’s  state  of  knowledge. 

In  particular,  the  paradigm  does  not  allow  for  an  explicit  model  of  the  environment  maintained  by 
the  task  agent  by  applying  domain-specific  inference  rules  to  data  (including  both  direct  observations 
and  previous  inferences)  and  updating  the  model  to  incorporate  the  results.  In  this  alternative 
paradigm,  advice  that  refers  to  the  environment  is  evaluated  relative  to  the  model.  For  instance,  one 
inference  rule  for  Hearts  is  “If  suit  S  is  led  and  player  P  plays  a  card  in  some  other  suit,  assert  that 
player  P  is  void  in  suit  S.”  The  task  agent  would  apply  this  rule  upon  observing  an  opponent  break 
suit  To  follow  die  advice  “Don’t  lead  a  high  card  in  a  suit  where  an  opponent  is  void.”  the  task  agent 
would  search  its  model  for  assertions  of  the  form  "player  P  is  void  in  suit  S”  and  choose  a  suit  for 
which  it  found  no  such  assertions. 

This  is  actually  an  approach  to  the  integration  problem  mentioned  earlier:  it  assumes  that 
translating  domain  knowledge  into  forward  inference  rules,  using  them  to  maintain  a  model  of  the 
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environment,  and  evaluating  advice  relative  to  the  model  will  lead  to  task  performance  consistent 
with  the  advice.  In  contrast,  the  approach  taken  in  this  dissertation  deduces  information  as  needed 
(although  some  of  the  operationalization  strategies  involve  explicit  decisions  to  remember  specific 
kinds  of  information  for  later  use).  The  two  approaches  are  closely  related:  many  of  the  techniques 
developed  in  the  dissertation  could  be  used  to  translate  domain  knowledge  into  forward  inference 
rules. 

In  the  model  of  Figure  1-1,  a  piece  of  advice  can  be  non-operational  for  the  task  agent  for  any  of 
several  reasons.  It  may  require  evaluating  a  quantity  defined  in  terms  of  unobservable  data  or  an 
unpredictable  future  event.  Similarly,  it  may  require  achieving  a  goal  that  is  not  expressed  as  a  doable 
action  or  that  depends  on  an  uncontrollable  choice  made  by  some  other  agent. 

1.1.2.  Definition  of  Operationalization 

Suppose  tire  agent  is  a  computer  program  with  a  few  rudimentary  card-playing  capabilities:  it  has 
procedures  for  observing  the  cards  in  its  hand,  deciding  whether  it  can  legally  play  a  card,  and 
moving  a  card.  It  has  no  inferential  ability,  but  it  has  a  mechanism  similar  to  LISP's  EVAL  for 
executing  procedures  and  evaluating  expressions,  augmented  by  a  few  features  like  three- valued  logic 
(true,  false,  and  unknown)  and  the  ability  in  a  given  task  situation  to  try  alternative  evaluation 
methods  (partial  definitions)  for  a  given  function  to  find  one  that  works  (returns  a  result).  Assume 
also  that  it  can  deal  with  historical  references,  Le.,  can  remember  the  value  that  an  expression  had  at  a 
specified  time  in  the  past,  how  many  times  a  described  event  occurred  over  a  specified  time  span,  and 
so  forth. 

What  does  it  mean  to  operationalize  Hearts  advice  for  such  an  agent?  Typically,  it  involves 
figuring  out  how  to  achieve  some  condition  or  evaluate  some  quantity.  For  example,  to  make  the 
advice  "avoid  taking  points"  operational  for  the  assumed  agent,  it  must  be  converted  into  a  plan  like 
“play  a  low  card."  This  is  a  plan  the  agent  can  execute,  assuming  it  has  a  test  for  deciding  whether  a 
card  is  low.  Thus  the  basic  problem  in  operationalizing  "avoid  taking  points”  is  of  the  form: 

Find  an  executable  plan  to  achieve  a  desired  condition. 

Another  kind  of  operationalization  problem  is: 

Find  an  effective  method  to  evaluate  a  relevant  quantity.2 

2One  could  rephrase  such  a  problem  as  "Achieve  a  slate  in  which  I  know  the  value  of  the  quantity."  but  this  approach  runs 
into  the  difficulties  associated  with  explicitly  representing  the  idea  of  knowing  something  (§4. 1)  (§8.3.2). 
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For  example,  consider  the  advice  “don’t  lead  a  high  card  in  a  suit  in  which  an  opponent  is  void.” 
The  agent  is  not  allowed  to  look  at  its  opponents’  cards.  Thus  the  operationalization  problem  here  is 
to  find  a  procedure  for  guessing  if  an  opponent  is  void  in  a  given  suit 

Both  kinds  of  problems  may  arise  in  operationalizing  a  single  piece  of  advice,  such  as: 

“If  an  opponent  has  the  Queen  of  spades,  try  to  flush  it” 

Following  this  advice  requires  evaluating  whether  an  opponent  has  the  Queen  of  spades  (without 
looking  at  opponents’  cards!)  and  achieving  the  goal  of  forcing  the  opponent  to  play  it. 

The  operationality  of  advice  is  affected  by  the  information  available  to  the  agent  receiving  iL  For 
example,  the  condition  “an  opponent  has  the  Queen  of  spades”  is  not  decidable  by  direct  observation 
in  Hearts  since  one  is  not  allowed  to  look  at  one’s  opponents’  cards.  Operationalizing  this  condition 
means  devising  a  way  to  evaluate  it.  The  condition  “the  cantus  must  contain  an  unrepeated  climax” 
is  non-operational  for  a  left-to-right  sequence  generator,  since  it  depends  on  the  complete  sequence, 
not  just  the  portion  that’s  been  generated  so  far. 

Operationality  can  depend  on  the  behavioral  limitations  of  the  task  agent.  For  example,  the  advice 
“flush  out  the  Queen  of  spades”  can’t  be  satisfied  by  plucking  the  Queen  from  the  hand  of  the 
opponent  holding  it,  since  the  rules  of  Hearts  restrict  players  to  playing  cards  from  their  own  hands. 

Operationality  can  depend  on  the  computational  limitations  of  the  task  agent.  For  example, 
“predict  me  consequences  of  playing  a  card  by  enumerating  all  possible  card  sequences  for  the 
round”  is  a  computationally  infeasible  way  to  avoid  taking  points.  Similarly,  "generate  all  tone 
sequences  of  the  desired  length  and  pick  one  that  satisfies  the  other  constraints”  is  not  a  feasible  way 
to  generate  a  cantus  firmus.  Thus  operationalization  includes  the  problem  of  making  theoretically 
executable  computations  efficient  enough  to  be  feasible.  The  distinction  between  this  and  what  an 
optimizing  compiler  does  is  pardy  one  of  degree.  The  term  “operationalization”  applies  to  quantum 
speed-ups  based  on  high-level  understanding  of  the  task,  rather  than  to  small  improvements  based  on 
local  transformations  of  code.  Moreover,  such  speed-ups  may  be  achieved  by  settling  for  an 
approximation  of  the  original  advice  --  such  as  a  procedure  that  is  only  sometimes  executable,  or 
occasionally  produces  an  incorrect  result  This  approach  is  not  permissible  for  a  faithlui  compiler. 

Operationality  can  be  relative.  A  procedure  is  a  more  or  less  operational  form  for  a  piece  of  advice 
according  to 


§1.1.2.  Definition  of  Operationalization 


11 


1.  Its  applicability:  how  often  the  agent  can  execute  the  procedure. 

2.  Its  effectiveness:  how  often  executing  the  procedure  produces  the  desired  result. 

For  example,  consider  two  operationalizations  of  the  advice  “avoid  taking  a  trick  with  points”: 

1.  “Play  your  lowest  legal  card.” 

2.  “Underplay  another  card  in  the  trick.” 

The  first  is  always  applicable  but  not  always  effective,  since  the  agent’s  lowest  card  may  turn  out  to 
be  the  highest  card  played  in  the  trick.  In  contrast,  the  second  is  guaranteed  to  be  effective,  but  is 
only  applicable  when  the  agent  has  a  card  lower  than  a  card  already  played  in  the  trick. 

To  restrict  the  problem,  this  dissertation  makes  certain  assumptions.  Since  natural  language 
interpretation  is  beyond  the  scope  of  this  work,  the  initial  task  description  and  advice  are  assumed  to 
be  encoded  in  an  unambiguous  internal  representation.  To  avoid  the  problems  associated  with 
integrating  different  pieces  of  advice,  the  dissertation  only  considers  pieces  of  advice  that  can  be 
operationalized  independently  of  each  other,  and  then  integrated  subsequently,  say  as  different  terms 
in  an  evaluation  function.  Thus  each  piece  of  advice  is  encoded  as  an  expression  that  may  refer 
(implicitly  or  explicitly)  to  various  aspects  of  the  task,  but  not  to  other  pieces  of  advice.  This 
restriction  excludes  advice  whose  operationalization  depends  on  the  other  advice  given,  e.g.: 

“Play  a  card  that  satisfies  more  than  one  goal.” 

“Assume  an  opponent’s  action  is  motivated  by  the  same  reason  you’d  have  for  that  action.” 

Explicit  methods  for  achieving  or  evaluating  a  condition  are  also  excluded,  since  such  advice  is 
already  operational,  e.g.: 

“A  suit  is  safe  for  the  first  two  tricks  led  in  it.” 

‘To  avoid  taking  points,  play  a  low  card.” 

These  considerations  lead  to  a  definition  of  (partial)  operationalization  as: 

Transformation  of  a  well-defined  expression  into  a  procedure  that  will  (often)  be  feasible  for 
a  specified  mechanism  to  execute  using  the  data  and  actions  available  to  it  at  execution 
time,  and  whose  execution  will  (often)  produce  the  result  described  by  the  original 
expression. 
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1.1J.  Thesis  of  the  Dissertation 

The  goal  of  this  dissertation  is  to  explore  the  kinds  of  knowledge  useful  in  operationalizing  advice. 
The  underlying  thesis  is  that 

There  exist  general  operationalization  methods  that  can  be  stated  independently  of  any 
specific  task  domain,  although  applying  them  generally  requires  domain- specific  knowledge. 


1.2.  Method  of  Investigation 

This  thesis  was  tested  by  following  the  plan  of  research  described  below. 

1.  Select  a  task  domain.  (§1.2.1) 

2.  Construct  a  problem  space  for  operationalization.  (§1.2.2) 

3.  Generate  example  problems,  operators,  and  solution  paths  in  this  space.  (§1.2.3) 

4.  Test  generality  on  examples  from  a  second  task  domain.  (§1.2.4) 

5.  Test  operationality  of  generated  solutions.  (§1.2.5) 

1.2.1.  Selecting  a  Task  Domain 

The  task  of  playing  the  card  game  Hearts  was  selected  as  a  good  vehicle  for  exploring 
operationalization.  The  Hearts  environment  is  easily  to  model,  and  the  rules  of  legal  play  are  simple, 
so  the  overhead  of  using  it  as  an  experimental  vehicle  is  small  compared  to  tasks  requiring  large 
amounts  of  specific  world  knowledge,  such  as  understanding  international  relations  [Carboncll  78]  or 
planning  synthesis  experiments  in  molecular  genetics  [Martin  77). 

Although  the  game  of  Hearts  is  easy  to  describe,  it  is  hard  to  win.  Hearts  involves  multiple  agents, 
each  of  whom  has  partial  information  (you  can’t  see  your  opponents’  hands)  and  partial  autonomy 
(you  can  play  a  card  only  from  your  own  hand,  only  in  your  own  turn,  and  only  if  it’s  a  legal  card  for 
you  to  play).  Thus  it  contrasts  with,  say,  the  blocks-world  task,  where  there  is  a  single  agent  with  a 
complete  model  of  the  world  and  the  freedom  to  perform  any  physically  possible  operation  at  any 
time. 

There  is  no  apparent  algorithm  for  winning  at  Hearts,  but  a  varied  collection  of  advice  on  how  to 
play  well  provides  a  rich  source  of  operationalization  problems.  For  example,  operationalizing  the 
advice  “don’t  lead  a  suit  in  which  an  opponent  is  void"  involves  devising  a  way  to  decide  if  an 
opponent  is  void  in  a  given  suit. 
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Appendix  A.1  describes  the  rules  of  Hearts  and  the  advice  use  in  later  examples. 

1.2.2.  Building  a  Problem  Space 

A  problem  space  for  operationalization  was  built,  consisting  of  a  representation  and  a  set  of 
operators  on  it.  The  states  in  the  problem  space  are  expressions  in  an  unambiguous  LISP- like 
language,  described  in  (§1.3).  The  operators  are  rules  that  transform  expressions.  Given  a  piece  of 
advice  encoded  as  an  expression,  the  problem  is  to  find  a  sequence  of  rules  that  transforms  it  into  an 
operational  expression,  where  “operational"  is  defined  relative  to  the  assumed  runtime  interpreter.  A 
sequence  of  expressions  leading  via  such  transformations  from  an  initial  piece  of  advice  to  an 
operationalization  of  it  is  called  a  derivation. 

The  300  or  so  transformation  rules  are  implemented  in  a  300K  LISP  program  called  FOO,  for 
"First5  Operational  Operationalizer.”  The-rules  are  the  major  product  of  the  research,  Le..  most  of  the 
dissertation  consists  of  statements  about  them.  They  arc  general  in  that  they  don't  refer  directly  to 
the  task  domain,  but  they  access  a  domain  knowledge  base.  The  problem  space  is  discussed  in  more 
detail  in  (§  1.2.7),  and  the  representation  of  domain  knowledge  is  described  in  (§1.3). 

foo  has  no  problem-solving  component:  it  can  apply  a  rule,  but  it  doesn't  know  what  rule  to 
apply  to  a  given  expression,  or  even  when  to  halt  because  the  expression  is  operational.  Thus  the 
dissertation  factors  operationalization  into  two  problems  --  formulating  the  problem  space  and 
solving  problems  in  this  space  --  and  neglects  the  second  in  order  to  concentrate  on  die  first.  It 
demonstrates  diat  mechanical  reasoning  padis  exist  in  the  space,  but  docs  not  solve  the  search  control 
problem  involved  in  finding  such  paths.  (§7)  proposes  an  approach  to  this  problem. 

1.2.3.  Generating  Examples 

I  encoded  several  pieces  of  advice  as  expressions  and  operationalized  each  one  by  applying  a 
sequence  of  transformation  rules,  adding  new  rules  as  needed.  At  each  point  in  die  sequence,  1  chose 
which  rule  to  apply  and  which  sub-expression  to  apply  it  to,  but  the  actual  application  was  performed 
by  FOO.  In  cases  where  applying  a  rule  involved  making  some  selection,  e.g..  choosing  from  a  set  of 
concepts  retrieved  by  FOO  from  its  knowledge  base,  I  made  the  selection.  I  also  decided  when  to 
declare  an  expression  operational  and  terminate  the  sequence. 
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The  derivations  of  operational  forms  for  Hearts  advice  generated  in  this  interactive  mode  are 
designated  DER1V2  through  DERIVL2,  and  appear  in  Appendix  D.  (§1.2.3. 1)  summarizes  the 
derivations  by  showing  the  initial  and  final  expressions  and  mentioning  the  kernel  ideas.  For 
example,  in  DERIV3,  '‘flush  the  Queen”  is  operationalized  as  "keep  leading  spades  until  the  Queen 
is  played”  by  applying  a  general  plan  for  depleting  a  set.  (§1.2.3.2)  describes  the  criteria  used  to  select 
the  advice  operationalized  in  the  derivations. 

1.13.1  Derivation  Summaries 

The  derivations  generated  using  TOO  are  designated  DERIV2  through  DERIV14,  and  are 
described  below. 


DERIV2  operationalizes  ‘‘avoid  taking  points”  as  a  heuristic  search  procedure  (§3)  that  tries  to  find 

a  scenario  in  which  playing  a  given  card  leads  to  taking  points. 

DERIV2  #STEPS  105  —DOMAIN:  HEARTS 

--PROBLEM:  ( AVOID-TAKING-POINTS  (TRICK)) 

--SOLUTION:  heuristic  search  in  space  of  card  sequences 


DF.R1V3  operationalizes  “flush  the  Queen  of  spades"  as  "keep  leading  spades”  by  instantiating  a 

general  plan  for  depicting  a  set  (§2.5),  analyzing  the  titles  of  legal  play,  and  applying  knowledge 

about  constraining  someone  else’s  choices  (§2.7). 

DERIV3  ESTEPS  93  --DOMAIN:  HEARTS 

--PROBLEM:  (ACHIEVE  (FLUSH  QS ) ) 

--SOLUTION:  (UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))) 


DERIV4  uses  the  pigeon-hole  principle  (§2.2)  and  case  analysis  (§5.7.1)  to  operationalize  “the 
Queen  of  spades  is  out”  as  “the  Queen  is  not  in  the  pot,  it’s  not  the  hole  card,  1  don’t  have  it,  and  it 
hasn't  been  taken.” 

DERIV4  #STEPS  55  --DOMAIN:  HEARTS 
--PROBLEM:  (EVAL  (QS-OUT)) 

--SOLUTION; 

(EVAL  (NOT  (OR  [IN-POT  QS]  [AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  QS]))) 


DERIV5  modifies  the  plan  derived  in  DERIV3  for  flushing  the  Queen  so  as  to  avoid  taking  the 
Queen  oneself.  This  example  illustrates  a  strategy  for  integrating  multiple  goals  (§2.10). 

0ERIV5  ESTEPS  53  --DOMAIN:  HEARTS 

--PROBLEM:  (AND  [ACHIEVE  (FLUSH  QS)]  [AVOID  (TAKE  ME  QS)  (TRICK)]) 
—SOLUTION:  (UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD -SAFE -SPADE  ME))) 


DERIV6  operationalizes  the  advice  “avoid  taking  points"  as  “play  a  low  card"  by  reformulating  it 
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in  terms  of  a  choice  variable  (§4).  A  variant  solution,  “underplay  the  King  of  diamonds,”  assumes  a 
situation  in  which  the  King  of  diamonds  has  been  led.  This  example  illustrates  that  operationalizing 
advice  in  the  context  of  a  specific  task  situation  may  produce  a  more  effective  but  less  general 
solution. 


0ERIV6  ESTEPS  62  --DOMAIN:  HEARTS 

--PROBLEM:  ( AVOID-TAKING-POINTS  (TRICK)) 

--SOLUTION: 

(ACHIEVE  (*>  (AND  [IN-SUIT-LED  (CARD-OF  ME)]  [TRICK-HAS-POINTS] ) 
(LOW  (CARD-OF  ME)))) 

--VARIANT-SOLUTION: 

(ACHIEVE  (=>  (AND  [IN-SUIT-LEO  (CARD-OF  ME)]  [TRICK-HAS-POINTS]) 
(LOWER  (CARD-OF  ME)  DK))) 


DERIV7  operationalizes  “get  the  lead”  as  “play  a  high  card  in  the  suit  led."  The  reformulation  of 

“win  the  trick”  as  a  predicate  on  player  ME's  card  is  borrowed  from  DERIV6. 

DERIV7  #STEPS  8  --DOMAIN:  HEARTS  —PROBLEM: 

(ACHIEVE  (LEADING  ME)) 

--SOLUTION: 

(ACHIEVE  (AND  [IN-SUIT-LED  (CARD-Ot  ME)]  [HIGH  (CARD-OF  ME)])) 


DERIV8  operationalizes  “get  void  in  suit  SO”  as  “keep  playing  cards  in  suit  SO”  by  applying  the 

same  set  depletion  strategy  used  in  DERIV3  (§2.5). 

DERIV8  #STEPS  14  —DOMAIN:  HEARTS 

--PROBLEM:  (ACHIEVE  (VOID  ME  SO)) 

--SOLUTION:  (UNTIL  (VOID  ME  SO)  (ACHIEVE  (PLAY-SUIT  ME  SO))) 


DERIV9  operationalizes  the  predicate  “player  PO  is  void  in  suit  SO"  probabilistically  as  a 
decreasing  function  of  the  number  of  cards  still  out  in  suit  SO.  This  is  accomplished  by  applying  a 
general  formula  for  the  probability  that  two  sets  arc  disjoint  (§2.3),  and  then  analyzing  die  functional 
dependence  of  this  formula  on  the  parameter  SO  (§2.8). 

DERIV9  #STEPS  59  —DOMAIN:  HEARTS 

--PROBLEM:  (EVAL  (VOID  PO  SO)) 

—SOLUTION:  (FUNCTION-OF  (#CARDS-OUT-IN-SUIT  SO)  DECREASING) 


DERIV10  uses  historical  reasoning  (§2.4)  to  derive  a  procedure  for  counting  the  number  of  cards 


out  in  suit  SO. 
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DERIV10  #STEPS  31  --DOMAIN:  HEARTS 

--PROBLEM:  (EVAL  (#CARDS-OUT- IN-SUIT  SO)) 

--SOLUTION: 

(EVAL  (-  (-  13 

(#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND- IN- PROGRESS) 
(HAS  ME  XI))))) 

(d»  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND- IN-PROGRESS) 
(EXISTS  P3  (OPPONENTS  ME) 
(PLAY  P3  XI))))))) 


DERIV11  operationalizes  the  predicate  “player  PO  is  void  in  suit  SO”  as  “player  PO’s  card  is  not  in 

the  suit  led”  by  applying  a  general  strategy  for  finding  a  sufficient  condition  (§2.6). 

DERIVll  #STEPS  18  --DOMAIN:  HEARTS 

--PROBLEM:  (EVAL  (VOID  PO  SO)) 

—SOLUTION: 

(EVAL  (AND  [BREAKING-SUIT  PO] 

[=  (SUIT-LED)  SO] 

[FOLLOWING  PO])) 


DERIV12  uses  historical  reasoning  (§2.4)  to  operationalize  the  predicate  “player  PO  is  void  in  suit 

SO”  as  “player  PO  was  void  earlier  in  the  round.” 

DERIV12  jFSTEPS  13  --DOMAIN:  HEARTS 

--PROBLEM:  (EVAL  (VOID  PO  SO)) 

--SOLUTION: 

(EVAL  (WAS-DURING  (CURRENT  ROUND-IN-PROGRESS)  (VOID  PO  SO))) 


DERIV13  operationalizes  the  task  of  composing  a  canius  firmus  (musical  tone  sequence)  satisfying 

certain  constraints  as  a  heuristic  search  procedure  (§3)  incorporating  the  constraints  as  generators, 

tests,  and  precomputed  data  structures. 

OERIV13  iFSTEPS  116  --DOMAIN:  MUSIC 

--PROBLEM:  (ACHIEVE  ( LEGAL-CANTUS !  (CANTUS))) 

--SOLUTION:  heuristic  search  in  space  of  tone  sequences 


DER1V14  reformulates  the  constraint  that  the  climax  tone  of  the  cantus  should  only  occur  once  in 
it  as  a  goal  to  be  achieved  over  time  (§2.11),  and  operationalizes  this  goal  in  a  way  that  doesn't  require 
selecting  the  climax  tone  before  generating  the  cantus. 
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0ERIV14  #STEPS  87  --DOMAIN:  MUSIC  --PROBLEM: 

(ACHIEVE  (=  (^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  1)) 
--SOLUTION: 

(FORALL  T 1  (LB:UB  0  (-  (#  CANTUS)  I)) 

(OR  [AND  [  =  (^OCCURRENCES  (CLIMAX  (CANTUS-1  Tl)) 

(CANTUS- 1  Tl)) 

1] 

[LOWER  (NOTE  (+  Tl  1)) 

(CLIMAX  (CANTUS-1  Tl))]] 

[HIGHER  (NOTE  (+  Tl  1))  (CLIMAX  (CANTUS-1  Tl))])) 


1.2.3.2  Selection  Criteria 

An  important  criterion  in  selecting  advice  to  operationalize  was  to  choose  examples  that  were 
challenging  but  could  be  solved  by  means  of  general  principles,  without  sneaking  in  the  solution  as 
pan  of  the  inpuL  For  example,  “lead  a  safe  suit”  was  rejected  because  the  only  obvious  definitions  . 
for  “safe"  were  cither  already  operational  or  else  too  vague  to  formalize. 

Diversity  was  also  a  consideration  in  choosing  examples.  For  example,  three  quite  different 
approaches  were  applied  to  the  problem  of  deciding  whether  an  opponent  is  void,  as  shown  in 
DER1V9  (§2.3),  DERIV11  (g2.6.2),  and  DHRIV12  (§2.4.2). 

Another  motivation  was  to  encode  knowledge  about  A!  methods.  The  most  sophisticated  method 
encoded  was  the  heuristic  search  method  (HSM).  In  DERIV2,  the  advice  “avoid  taking  points"  was 
operationalized  as  a  heuristic  search  problem  by  mechanically  deriving  an  appropriate  state  space  and 
search  control  heuristics  from  the  representation  of  the  advice  (§3). 

The  goal  of  the  research  was  to  capture  general  knowledge  about  operationalization  rather  than 
achieve  good  task  performance  at  the  cost  of  ad  hoc  methods.  Pursuing  this  goal  did  not  require 
getting  FOO  to  play  Hearts,  and  in  fact  it  doesn’t 

Because  of  this  emphasis  on  generality,  only  a  few  examples  were  treated  relative  to  the  range  of 
potentially  useful  advice  and  the  variety  of  operationalization  methods  applicable  to  it.  foo’s 
collection  of  methods  is  a  small  and  arbitrary  sampling,  neither  complete  nor  representative.  As  an 
exploration  of  knowledge  used  in  operationalization,  this  work  is  a  beginning  step  in  a  large  space. 
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1.2.4.  Testing  Generality 

To  test  the  generality  of  the  approacu,  a  music  generation  problem  was  selected  as  a  second  task 
and  operationalized  using  foo  in  the  interactive  mode  described  above,  adding  rules  as  necessary. 
The  problem  was  inspired  by  an  existing  prog;._m  for  composing  cantus  firmus  [Meehan  72J;  the 
program  incorporated  aesthetic  constraints  from  a  music  text  [Salzer  69].  The  task  used  to  test  ixxj’s 
generality  was  based  on  a  subset  of  these  constraints.  In  DER1V13,  this  task  was  operationalized  as  a 
heuristic  search  problem  using  many  of  the  same  rules  used  to  operational1  z-*  “avoid  taking  points”  in 
DERIV2.  In  DERIV14,  an  alternative  operationalization  was  derived  for  one  of  the  task  constraints. 

1.2.5.  Testing  Operationality 

A  potential  problem  with  this  method  of  investigation  was  the  use  of  a  subjective  criterion  for 
deciding  when  to  terminate  the  interactive  operationalization  process  and  accept  the  resulting 
expression  as  operational.  To  address  this  problem,  the  operationality  of  each  derived  expression  was 
analyzed  by  a  simple  procedure,  as  shown  in  Appendix  E.  Instead  of  returning  a  simple  yes-or-no 
result,  the  procedure  finds  a  set  of  conditions  under  which  the  expression  will  be  operational. 
Making  a  yes-or-no  decision  would  require  the  ability  to  predict  what  information  will  be  known 
when  an  expression  is  evaluated  (§8.1.1).  The  issue  is  further  complicated  by  the  fact  that  an 
operationalization  can  be  better  or  worse  depending  on  such  factors  as  how  often  it  can  be  applied, 
how  much  it  costs,  and  how  often  it  produces  the  desired  result. 

As  the  operationality  analysis  shows,  some  of  the  expressions  were  only  partly  operational  or 
assumed  the  solution  of  other  operationalization  problems.  For  example,  the  plan  generated  in 
DERIV5  for  flushing  the  Queen  of  spades  without  taking  it  is:  “keep  leading  safe  spades  until  the 
Queen  is  played.”  The  success  of  this  plan  depends  on  getting  and  keeping  the  lead,  and  having 
enough  spades  to  last  until  the  Queen  is  flushed.  Deciding  whether  the  preconditions  for  success  are 
satisfied  is  difficult  For  example,  the  distribution  of  spades  is  unknown,  so  it’s  uncertain  how  many 
are  “enough.”  Moreover,  the  plan  may  succeed  even  when  the  preconditions  arc  not  satisfied,  for 
example  if  other  players  help  out  by  also  leading  spades.  The  problem  of  getting  the  lead  is 
addressed  in  DERIV7,  but  none  of  the  derivations  solve  die  problems  of  keeping  the  lead  or  deciding 
whether  one  has  enough  spades. 

The  plan  produced  in  DERJV5  is  partly  operational  insofar  as  it  will  sometimes  be  executable  and 
when  executed  will  sometimes  succeed  in  flushing  the  Queen.  A  proposed  approach  for  improving 
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such  a  partly  operational  plan  is  to  use  it  until  it  fails  to  work,  diagnose  the  problem  dial  caused  the 
plan  to  fail,  and  modify  the  plan  to  prevent  that  problem  from  recurring  [Hayes-Roth  81a|.  DER1V5 
actually  illustrates  the  last  phase  of  this  approach,  since  it  consists  of  modifying  a  plan  for  flushing  the 
Queen  (derived  in  DER1V3)  so  as  to  avoid  taking  the  Queen  oneself. 

1.2.6.  Organization  of  Results 

The  results  of  the  investigation  described  above  arc  organized  according  to  the  kinds  of  knowledge 
used  in  operationalization.  (§2)  presents  general  operationalization  ideas  underlying  several 
derivations,  and  (§3)  describes  foo’s  knowledge  about  the  heuristic  search  method.  (§4)  discusses  die 
crucial  process  of  problem  reformulation,  which  figures  throughout  the  derivations.  Typically  only 
one  or  two  of  the  rules  used  in  a  derivation  express  general  ideas  about  operationalization;  die  rest  of 
the  derivation  consists  of  the  analysis  required  to  apply  diese  general  ideas  to  the  problem  at  hand. 
(§5)  describes  the  methods  used  to  perform  this  analysis.  (§6)  tells  how  task  domain  knowledge  is 
“used  in  operationalizauon.  These  chapters  draw  support  and  examples  from  the  derivations 
generated  using  FOO  in  the  interactive  mode  described  above. 

1.2.7.  A  Problem  Space  for  Operationalization 

The  problem  space  in  which  FOO  works  can  now  be  described  more  precisely.  A  problem  consists 
of  a  piece  of  advice  to  be  operationalized,  encoded  as  an  S-exprcssion  in  a  I.ISP-likc 
language  [McCarthy  63]  described  in  detail  in  (§1.3.1).  This  language  uses  prefix  notation;  an 
expression  (f  ct ...  cn)  denotes  the  result  of  applying  the  function  f  to  the  arguments  Cj  ...  cn,  where  f, 

et .  cn  may  themselves  be  expressions.  An  expression  of  the  form  (achieve  P)  represents  the 

problem  “find  an  operational  procedure  for  achieving  P.”  An  expression  of  the  form  (eval  e) 
represents  the  problem  "find  an  operational  procedure  for  evaluating  c.”  Thus  the  expression 
(ACHIEVE  (VOID  ME  SO))  represents  die  problem  of  gelling  void  in  suit  SO,  while 
( EVAL  (VOID  PO  SO ) )  represents  the  problem  of  deciding  vhether  player  PO  is  void  in  suit  SO. 

A  solution  to  such  a  problem  is  an  expression  that  the  assumed  runtime  interpreter  can  interpret  to 
produce  the  desired  result.  For  example,  (UNTIL  (VOID  ME  SO)  (PLAY-SUIT  me  SO))  is  a  plan 
for  getting  void  in  suit  SO  by  successively  playing  cards  in  that  suic  while  the  expression 
(FUNCTION-OF  (#CARDS-OUT- IN-SUIT  SO)  DECREASING)  describes  a  probabilistic  method  for 
guessing  whether  an  opponent  is  void  in  suit  SO;  it  characterizes  the  probability  of  a  void  as  a 
decreasing  function  of  the  number  of  cards  still  out  in  suit  SO.  This  characterization  can  be  used  to 
order  the  suits  according  to  the  relative  probabilities  of  an  opponent  being  void  in  them. 
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A  solution  path  or  derivation  in  the  problem  space  is  a  scries  of  expressions  leading  from  a  problem 
to  a  solution,  where  each  expression  is  the  result  of  applying  some  transformation  to  the  previous 
one.  Certain  (overlapping)  classes  of  transformations  are  worth  identifying: 

1.  A  valid  transformation  preserves  semantic  equivalence,  Le.,  transforms  an  expression  to  another 
with  the  same  meaning. 

2.  A  sound  transformation  changes  a  logical  condition  to  an  equivalent  or  stronger  one,  Le.,  never 
transforms  falsehood  into  truth.  All  valid  transformations  are  sound. 

3.  A  useful  transformation  changes  an  expression  into  one  that  is  closer  to  being  operational.  A 
transformation  may  be  useful  but  not  valid  or  sound,  and  vice  versa.  The  problem  of  predicting 
whether  a  transformation  will  prove  useful  is  beyond  the  scope  of  the  dissertation  but  must  be 
addressed  as  part  of  building  a  problem-solver  for  this  space  (§7). 

An  operator  in  the  problem  space  is  a  rule  for  transforming  an  expression.  A  rule  has  the  form 
RUI.Ennn:  <lhs>  ->  <rhs>  if <condition> 

The  <Ihs>  and  <rhs>  are  patterns  that  can  contain  pattern-match  variables  and  embedded 
procedure  calls.  The  <condition>  is  a  predicate  that  can  refer  to  the  variables.  To  apply  a  rule  to  an 
expression,  FOO  matches  the  <lhs>  of  the  rule  to  the  expression,  binds  the  variables  in  the  <lhs>  to  the 
corresponding  components  of  the  expression,  verifies  the  <condition>,  replaces  variables  in  the  <rhs> 
with  their  bindings  from  the  match,  executes  any  procedure  calls  embedded  in  the  <rhs>,  and  returns 
the  resulting  expression.  If  the  rule  was  applied  to  a  sub-expression  of  an  overall  problem,  TOO 
transforms  die  problem  by  replacing  the  sub-expression  with  the  result  of  applying  the  rule  to  it 
Typically  the  existence  of  a  match  and  the  satisfaction  of  the  <condition>  guarantee  that  applying  the 
rule  will  produce  a  valid  or  sound  (but  not  necessarily  useful)  transformation. 

For  example,  one  of  the  rules  in  FOO  is 

RUI.F43:  (R  (fex ...  c^ffe^ ...  en’))  ->  (and  [=  e1el']...t=  e[t  en’])  if  R  is  reflexive 

For  some  rules,  verifying  the  <condition>  or  evaluating  the  <rhs>  involves  establishing  a 
subproblcm  and  applying  other  rules  to  it.  Thus  a  problem  stale  in  the  operationalization  process 
may  contain  a  stack  of  expressions  representing  subproblcins  (§5.9.3).  In  addition,  die  problem  state 
may  include  various  global  assumptions  and  variable  bindings  used  to  facilitate  communication 
between  different  problems  (§5.4). 

The  rules  shown  in  later  examples  are  expressed  in  an  informal  notation  that  sacrifices  some 
precision  in  favor  of  readability.  For  example,  a  rule  containing  the  pattern  (P  ...  e  ...)  in  its  <lhs>  is 
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ambiguous  in  that  it  doesn't  specify  whether  e  can  be  nested  arbitrarily  deeply  or  must  be  a  top-level 
argument  of  P,  If  the  rule  is  applied  to  an  expression  containing  more  than  one  sub-expression  that 
matches  c,  this  informal  notation  doesn't  specify  whether  to  replace  one,  some,  or  all  of  the  sub¬ 
expressions  matching  e.  Appendix  B  lists  FOO’s  transformation  rules  in  a  precise,  machine-generated 
format  and  explains  in  more  detail  how  they  are  applied. 

Although  the  rules  are  general,  they  can  access  a  domain-specific  knowledge  base.  Domain 
knowledge  is  stored  in  various  forms.  For  example,  the  fact  that  a  domain-specific  conr„pt  like  VOID 
is  an  instance  of  a  general  concept  like  PREDICATE  is  encoded  in  an  is-a  hierarchy.  This  enables  foo 
to  apply  general  rules  to  domain-specific  expressions.  Concept  definitions  are  encoded  as  lambda 
expressions  in  the  same  language  used  to  encode  problems  and  solutions.  This  enables  foo  to  apply 
knowledge  about  a  concept  used  in  a  problem  simply  by  replacing  the  concept  with  its  definition, 
provided  it  knows  the  concept's  definition.  (FOO  doesn't  have  a  definition  for  every  concept  it  knows 
about.)  For  example,  the  definition  "being  void  in  a  suit  means  having  no  cards  in  that  suit”  is 
encoded  as 

VOID  «  (LAMBDA  (P  S) 

(NOT  (EXISTS  Cl  (CARDS-IN-HAND  P)  (IN-SUIT  Cl  S) ) ) ) 

The  variable  names  P.  S,  and  Cl  have  no  inherent  significance,  Le..  variables  are  not  typed. 

A  definition  may  itself  refer  to  domain-specific  concepts  whose  definitions  refer  to  lower-level 
concepts,  and  so  forth.  For  example,  the  concept  of  the  cards  held  by  a  player  is  defined  by 
CARDS-IN-HAND  =  (LAMBDA  (P)  (SET-OF  Cl  (CARDS)  (HAS  P  Cl))) 

The  derivation  of  a  plan  for  getting  void  (DERIV8)  involves  elaborating  the  concept  of  being  void 
in  terms  of  the  concept  of  a  card  being  at  a  location.  This  allows  the  application  of  the  general 
knowledge  that  the  way  to  cause  an  object  to  stop  being  at  a  location  is  to  move  it,  and  the  domain- 
specific  knowledge  that  in  Hearts  a  legal  way  to  move  a  card  is  to  play  it. 


1.3.  Representation  of  Conceptual  Knowledge 

The  concepts  used  in  FOO  can  be  classified  into  two  broad  categories:  general  and  domain- specific. 
Most  of  FOO’s  knowledge  about  domain-specific  concepts  is  encoded  in  the  form  of  concept 
definitions  in  a  language  described  in  (§1.3.1).  For  example,  the  fact  that  “taking  points"  means 
“taking  a  point  card"  is  encoded  as 

TAKE-POINTS  =  (LAMBDA  (P)  (FOR-SOME  C  (POINT-CARDS)  (TAKE  P  C))) 
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Most  of  FOO's  knowledge  about  the  general  concepts  used  in  rules  is  encoded  in  an  is-a  hierarchy 
whose  terminal  nodes  include  some  domain-specific  concepts.  Thus  the  fact  that  “taking  points"  is 
an  action  is  encoded  as 

TAKE-POINTS  1s-a  ACTION 

A  few  other  relations  arc  encoded  in  a  semantic  network.  One  fact  encoded  in  the  network  is 
OPPOSITE  of  HIGH  is  LOW 

The  is-a  hierarchy  and  semantic  network  are  described  in  (§1.3.2).  Finally,  a  few  facts  about  the 
domain  are  encoded  as  “fact  rules,"  presented  in  (§1.3.3).  For  example,  the  fact  that  there  are  13 
cards  in  each  suit  is  encoded  as 

RULE376:  (#  (cards- in-suits))  ->  13 

The  various  ways  in  which  foo  uses  conceptual  knowledge  are  discussed  in  (§6). 

The  rest  of  (§1.3)  describes  FOO’s  knowledge  representation  in  more  detail;  the  reader  may  wish  to 
skip  to  (§  1.4),  where  the  discussion  of  operationalization  resumes. 

13.1.  A  Language  for  Representing  Concepts 

FOO  uses  a  LISP-like  language  to  represent  concept  definitions,  problems,  and  solutions.  The 
representation  is  applicative  insofar  as  assignment  statements  and  goto’s  are  not  allowed,  but  certain 
constructs  depend  implicitly  on  the  current  state  of  the  task  environment.  For  example.  ( LOC  C )  is  a 
fluent  -  a  function  of  time  whose  value  is  the  location  of  card  C  at  time  t.  Similarly,  the  expression 
(CURRENT  TRICK)  denotes  the  instantiation  of  the  TRICK  scenario  current  at  time  L 

Atomic  symbols  denote  variables,  constants,  or  functions.  FOO  uses  three  kinds  of  variables: 

1.  Lambda  variables  arc  used  as  formal  arguments  in  concept  definitions. 

2.  Global  variables  are  generated  by  rules  to  represent  unknowns  in  equations. 

3.  Quantifier  variables  arc  used  in  quantified  expressions  of  the  form  (Q  x  S  c^). 

To  prevent  name  conflicts,  quantifier  variables  and  global  variables  arc  given  unique  names  like  Cl 
and  P4  whenever  they’re  generated.  A  variable  can  be  bound  to  a  value  at  most  once;  FOO’s 
representation  does  not  have  standard  programming  language  variables. 
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Atomic  symbols  other  than  variables  arc  treated  as  unevaluated  constants ,  eg.,  ME,  QS,  1.  This 
feature  difFers  from  LISP  semantics,  which  uses  the  QUOTE  construct  to  represent  non-numeric 
constants.  FOO  has  no  QUOTE  construct.  Note  that  the  same  symbol  can  be  a  lambda  variable  when 
used  inside  a  concept  definition  and  a  constant  elsewhere.  For  example,  S  is  sometimes  used  as  a 
lambda  variable  denoting  a  set,  but  otherwise  denotes  the  spade  suit. 

An  atomic  symbol  can  also  denote  a  function.  In  die  implementation,  atoms  are  marked  so  the 
system  can  distinguish  among  variables,  constants,  and  functions.  Concepts  are  represented  in  FOO  as 
LISP  functions,  using  LISP’s  built-in  mechanisms  for  encoding  and  editing  function  definitions. 
(Some  partial  definitions  are  encoded  as  rules  (§5.5).) 

Non-atomic  expressions  follow  LISP’s  prefix  notation.  There  are  four  kinds  of  list  expressions: 

1.  Lambda  expressions  have  the  form  (lambda  (Xj ...  xn)  <expression>). 

2.  Quantified  expressions  have  the  form  (Q  x  S  e^),  where  variable  x  ranges  over  set  S. 

3.  Extensional  collections have  the  form  (L  ...  efl),  where  L  is  a  list-ary  function. 

4.  Function  applications  have  the  form  (f  ej ...  en),  where  f  is  an  n-ary  function. 

1.3. 1.1  Lambda  Variables  versus  Slots 

The  lambda  variables  xt ...  xn  of  a  function  definition  f  =  (lambda  (x }  ...  xn)  <body>)  correspond 
to  the  “slots"  or  “facets”  of  the  concept  f,  but  FOO’s  representation  has  no  explicit  data  structure 
corresponding  to  the  type  constraints,  inheritance  information,  and  other  knowledge  often  attached 
to  such  components;  they  simply  weren’t  needed.  There  appear  to  be  three  reasons  for  this. 

First,  the  usual  purpose  of  such  information  in  an  AI  system  is  to  help  disambiguate,  complete,  or 
instantiate  a  concept,  but  the  problems  given  to  FOO  and  the  concept  definitions  used  in  solving  them 
are  encoded  to  begin  with  as  unambiguous,  well-formed  expressions.  Since  FOO  receives  well-formed 
input,  no  instantiation  or  disambiguation  is  needed  to  interpret  it.  Significantly,  the  treatment  of  the 
heuristic  search  method  in  FOO  does  involve  instantiating  a  schema,  and  FOO  has  knowledge  about 
individual  slots  of  that  schema,  encoded  as  rules  (§3.2). 

A  second  factor  obviating  the  need  for  slot  information  is  the  strong  typing  inherent  in  FOO’s 
representation.  Specifically,  the  only  variables  used  in  concept  definitions  arc  quantifier  variables, 
and  all  quantification  is  restricted  to  the  form  (Q  x  S  Px)  where  S  is  the  scope  of  variable  x. 

Finally,  I’ve  avoided  using  slots  when  functions  will  do,  an  approach  inspired  by  discussions  with 
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Stan  Roscnschein  (who  bears  no  responsibility  for  any  bugs  in  FOO’s  representation).  For  example,  a 
typical  AI  system  might  encode  the  fact  that  a  card  has  suit,  rank,  and  possibly  points  as  a  schema  for 
CARO  with  slots  for  SUIT,  RANK,  and  POINTS.  FOO  uses  Junctions  instead  of  annotated  slots.  For 
example,  the  function  SUIT-OF  returns  the  suit  of  a  given  card,  and  the  function  POINTS  returns  the 
number  of  points  a  given  card  has.  A  card  could  be  specified  by  its  suit  and  rank  by  defining  a 
function 

CARO  *  (LAMBDA  (SR) 

(THE  C  (CARDS) 

(ANO  [«  (SUIT-OF  C)  S]  [»  (RANK-OF  C)  R]))) 

/ 

1.3. 1.2  General  versus  Specific  Concepts 

Classifying  concepts  as  general  or  domain-specific  is  a  bit  simplistic.  The  concepts  in  FOO  span  a 
spectrum  of  generality,  with  Hearts-specific  concepts  like  TAKE-POINTS  at  one  extreme,  and 
immutable  mathematical  concepts  like  equality  at  the  other.  In  between  arc  card  game  concepts  like 
PLAY,  and  basic  concepts  like  MOVE  that  may  be  modelled  differently  in  different  domains.  For 
example,  rate  of  motion  is  irrelevant  in  Hearts  but  important  in  physics. 

Some  of  the  concepts  in  foo  are  extremely  specific,  like  #CARDS-0UT-IN-SUIT  and 
LEAD-SAFE-SPADE,  and  the  suspicious  reader  may  consider  them  evidence  that  I  sneaked  into  the 
knowledge  base  the  solutions  to  the  problems  solved  using  FOO.  These  concepts  are  simply  the  result 
of  giving  names  to  expressions  that  arose  naturally  in  the  course  of  operationalization.  For  example, 
(#C ARDS -OUT-  IN -SUIT  SUIT)  is  a  convenient  name  for  the  expression 
(#  (FILTER  (CARDS-  IN-SUIT  SUIT)  OUT ))  synthesized  by  one  of  the  methods  used  to  decide  if 
an  opponent  is  void  (§2.3).  Similarly,  (LEAD-SAFE-SPADE  P)  is  the  convenient  name  given  to  an 
expression  synthesized  in  the  course  of  operationalizing  the  advice  “flush  the  Queen  without  taking 
it”  (§2.10): 

(AND  [LEADING  P]  [SPADE!  (CARD-OF  P)]  [HIGHER  QS  (CARD-OF  P)]) 

This  particular  “definition  of  convenience”  can  be  criticized  on  the  grounds  that  it  doesn’t 
explicitly  mention  playing  a  card.  However,  omitting  it  from  the  knowledge  base  would  not  hinder 
the  synthesis  of  an  operational  plan  to  satisfy  the  advice,  only  its  expression  in  a  more  compact  form. 
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1.3.1  J  Concepts  Corresponding  to  Different  Parts  of  Speech 

Describing  1'OO's  concept  representation  as  a  “LISP-likc  language”  (§1.3.1)  fails  to  specify  how  to 
encode  a  given  concept.  This  section  tries  to  give  a  more  concrete  idea  of  how  knowledge  is  encoded 
in  practice  by  showing  how  concepts  corresponding  to  the  same  parts  of  speech  are  encoded  in 
similar  forms. 

Nouns  are  encoded  in  FOO  in  several  ways. 

1.  Constants  like  QS  and  ME  denote  named  objects  like  queen  of  spades,  system-as-player. 

2.  (the  x  S  P  )  denotes  a  singular  definite  noun  --  the  (unique)  x  in  S  satisfying  P.  Thus 
(OWNER-OF*C)  *  (THE  P  (PLAYERS)  (HAS  P  C ))  denotes  the  player  holding  card  C. 

3.  (set-of  x  S  P  )  or  (filter  S  P)  denotes  a  plural  definite  noun  --  those  x  in  S  satisfying  P: 
(CARDS-IN-POT)  =  (SET-OF  C  (CARDS)  (AT  c  POT ))  denotes  all  the  cards  in  the  pot. 

4.  A  quantifier  variable  x  in  (Q  x  S  P  )  denotes  a  singular  indefinite  noun: 
(OUT  C)  =  (EXISTS  P  (OPPONENTS  ME)  (HAS  P  C ))  means  “a  card  is  out  if  an  opponent 
has  it.” 

Adjectives  (predicates  and  noun  modifiers)  correspond  to  various  constructs  in  FOO. 

1.  Unary  predicates  denote  absolute  adjectives  like  HIGH. 

2.  Binary  relations  denote  comparatives  like  HIGHER. 

3.  (lambda  (S)  (the  x  S  (forall  y  S  (not  (R  y  x)))))  denotes  superlatives  like  HIGHEST. 

Note  that  this  representation  scheme  covers  predicates  and  their  intensions  --  “the  set  of  x 
satisfying  P,"  or  "the  unique  x  satisfying  P”  --  but  not  indefinite  nouns  like  "an  x  satisfying  P.” 

Action  verbs  arc  encoded  in  FOO  as  predicates.  An  action  (A  e1  ...  eft)  can  be  defined  as  a  fluent 
(function  of  time)  in  more  than  one  way,  e.g 

(lambda  (t)  Specified  action  starts  at  time  t>) 

(lambda  (tx  t^)  Specified  action  starts  at  time  tx  and  ends  at  time  t^>) 

In  practice,  expressions  denoting  actions  arc  manipulated  without  making  the  time  parameter 
explicit  An  example  of  an  action  verb  definition  is 

PLAY  «  (LAMBDA  (P  C)  (MOVE  C  (HAND  P)  POT )),  which  denotes  “playing  a  card  means 
moving  it  from  one’s  hand  to  the  pot."  It  is  unnecessary  to  make  P  an  explicit  argument  of  MOVE, 
since  in  the  game  of  Hearts  the  origin  and  destination  of  a  motion  uniquely  determine  its  agent.  The 
lowest-level  action  is  “fluent  F  becomes  C.”  encoded  as  (BECOME  F  C).  If  time  is  modelled 
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discretely  and  represented  by  the  integers,  “F  becomes  C  at  time  i”  can  be  interpreted  as  “F  equals  C 

at  time  i  + 1  but  not  at  time  i.”  This  enables  the  following  definitions: 

BECOME  * 

(LAMBDA  (F  C) 

[LAMBOA  (I)  (AND  [NOT  (*  (F  I)  C)]  [=  (F  (+  I  1))  C])]) 


MOVE  * 

(LAMBOA  (OBJ  ORIGIN  DESTINATION) 

(ANO  [  =  (LOC  OBJ)  ORIGIN]  [BECOME  (LOC  OBJ)  DESTINATION])) 

CAUSE  =  (LAMBDA  (P)  (BECOME  P  T)) 

UNDO  =  (LAMBDA  (P)  (BECOME  P  NIL)) 


Verbs  of  being  are  also  encoded  as  predicates.  Thus  (HAS  PC)  =  (AT  C  (HAND  P))  means  “a 
player  has  a  card  if  the  card  is  located  at  the  player’s  hand.” 


Adverbs  (action  modifiers)  arc  encoded  as  predicates. 

1.  The  condition  C  in  an  action  verb  expression  (while  C  A)  restricts  the  action  A.  This  is  nut  the 

standard  programming  language  sense  of  “while.” 

(LEAD  PC)  =  (WHILE  (LEADING  P)  (PLAY  P  C ))  denotes  “lead  card  C  means  play  C 
while  leading.” 

2.  A  proposition  conjoined  with  an  action  modifies  it,  since  actions  are  predicates.  Thus 
(PLAY-SPADE  P)  =  (AND  [PLAY  P  ?C]  [SPADE!  ?C] )  means  “play  a  spade.”  In  this  lazy 
notation,  the  variable  ?C  is  implicitly  existentially  quantified. 

3.  (Q  x  S  Ax)  denotes  an  indeterminate,  repealed,  or  choice-dependent  action.  For  example, 
(FOR-SOME  C  (POINT-CARDS)  (TAKE  P  C)))  denotes  “take  a  point  card”; 
(EACH  C  (CARDS- PLAYED)  (TAKE  P  C))  denotes  “take  all  the  cards  played”;  and 
(CHOOSE  (CARD-OF  P)  (LEGALCARDS  P)  (PLAY  P  (CARD-OF  P )))  denotes  “choose  a 
legal  card  and  play  it.” 

4.  (scenario  A1 ...  An)  denotes  a  sequence  of  actions.  For  example,  a  trick  is  defined  as 

(SCENARIO  (EACH  P  (PLAYERS)  (PLAY-CARD  P)) 

(TAKE-TRICK  (TRICK-WINNER))) 

5.  (until  C  A)  denotes  an  iterated  action.  For  example,  a  plan  for  flushing  the  queen  is 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))). 

6.  (was-during  S  A)  and  (before  S  A)  denote  past  tense:  “P  took  C  during  die  round ”  is  encoded 
as  (WAS-DURING  (CURRENT  ROUND- IN-PROGRESS)  (TAKE  P  C) ),  and  "C  was  out  when  the 
round  started”  as  (BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (OUT  C)). 

Attributes  arc  encoded  as  functions.  Thus  (it  S)  denotes  the  size  of  set  S,  and  (HAND  P)  denotes 
“player  P’s  hand”  (a  location,  not  the  set  of  cards  there).  Some  attributes  of  sets  are  defined  by 
projecting  attributes  of  the  set’s  members.  For  example,  “the  players’  hands"  is  encoded  as 
(HANOS  (PLAYERS)),  where  HANDS  =  (LAMBOA  (S)  (PROJECT  HAND  S)). 
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Prepositional  phrases  are  encoded  as  relations.  For  example,  “the  cards  in  the  pot "  is  encoded  as 
(SET'OF  C  (CAROS)  (AT  C  POT)),  and  “take  points  during  the  current  trick"  is  encoded  as 
(DURING  (CURRENT  TRICK)  (TAKE-POINTS  ME)).  Note  that  the  predicate  DURING  is  actually  a 
functional,  since  its  arguments  are  actions  (predicates).  Suppose  actions  are  modelled  as  predicates  of 
the  form 

(lambda  (tx  <action  starts  at  dme  t^  and  ends  at  time  t^>) 

Then  “A  occurs  during  S”  means  “if  S  occurs  over  some  time  interval,  A  occurs  in  a  sub-interval”: 

DURING  * 

(LAMBDA  (S  A) 

[FORALL  T 1  (TIME) 

(FORALL  T2  (TIME) 

(=>  [S  T 1  T2] 

[EXISTS  T3  (TIME) 

(EXISTS  T 4  (TIME) 

(AND  [A  T3  T4]  [=<  T1  T3]  [=<  T4  T2]))]))]) 

This  definition  is  shown  here  only  to  demonstrate  that  DURING  can  be  assigned  a  precise  meaning. 
With  its  quadruply  nested  quantification,  it  would  be  rather  unwieldy  to  reason  about,  and  it  is  not 
included  in  roo’s  knowledge  base. 

Connectives  are  encoded  using  standard  logical  operators: 

1.  (and  C, ...  C  )  is  true  when  all  of  C,  ...  C  arc  true  and  false  otherwise. 

'  l  n'  in 

2.  (or  Cx ...  Cn)  is  true  when  any  of  C: ...  Cn  are  true  and  false  otherwise. 

3.  (not  C)  is  true  when  C  is  false,  and  vice  versa. 

4.  ( =  >  C  C)  is  true  except  when  C  is  true  and  C’  is  false. 

5.  (if  C  e  e’)  denotes  “if  C  then  c  otherwise  e\”  where  e  need  not  be  boolean. 

The  concept  definitions  used  in  the  derivations  are  listed  in  Appendix  C.3. 

1.3.2.  Semantic  Relations 

Some  knowledge  in  FOO  is  encoded  as  semantic  relations  between  concepts.  The  most  common  of 
these  is  the  is-a  relation.  Since  this  relation  is  binary  and  anti-symmetric,  it  can  be  encoded  as  a 
lattice  (acyclic  graph)  with  unlabclled  arcs.  FOO  also  uses  a  few  other  binary  semantic  relations. 
These  are  encoded  in  a  graph  whose  arcs  arc  labelled  with  the  relation  name. 
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1.3.2.1  Is-a  Hierarchy 

The  concepts  used  in  FOO  are  organized  into  an  is-a  hierarchy.  The  hierarchy  is  tangled  in  that  a 
concept  may  have  more  than  one  immediate  generalization.  For  example,  the  SUBSET  relation  is 
both  REFLEXIVE  and  TRANSITIVE.  An  alternative  view  of  the  is-a  hierarchy  is  that  it  compactly 
encodes  concept  features  by  exploiting  subsumption  relations  between  features. 

The  hierarchy  contains  both  general  and  domain-specific  concepts.  For  example, 

TAKE-POINTS  Is-a  ACTION  Is-a  PREDICATE  is-a  FUNCTION  is-a  ANY-CONCEPT 

The  same  mechanism  is  used  to  distinguish  Hearts  concepts  from  music  concepts;  thus 
TAKE-POINTS  is-a  HEARTS  and  EXTEND  is-a  MUSIC.  This  helps  FOO  ignore  irrelevant  concepts 
when  searching  the  knowledge  base  for  concepts  of  a  given  form  (§6.5).  Note  the  loose  use  of  “is-a”; 
more  accurate  would  be  “has- feature"  or  “is-rclated-in-unspecified-way-to." 

FOO’s  is-a  hierachy  is  shown  in  Appendix  C.l. 

1.3.2.2  Semantic  Network 

Certain  semande  reladons  between  concepts  arc  encoded  using  LISP’s  property-list  (attribute- 
value  pair)  mechanism.  Since  they  are  all  binary  relauons  and  single-valued  functions  of  their  first 
argument,  they  can  be  expressed  as  facts  of  the  form  “the  <attribute>  of  <conccpi>  is  <valuc>"  and 
encoded  by  putting  the  ordered  pair  (<attribute>  <value>)  on  the  property  list  of  <conccpt>. 

This  representadon  is  useful  when  FOO  lacks  a  general  definition  for  <attributc>.  For  example,  it  is 
difficult  to  define  “opposite,”  but  it  is  important  for  FOO  lo  know  that  the  opposite  of  “high”  is 
“low.”  This  fact  is  represented  as  the  semande  relation 
OPPOSITE  of  HIGH  is  LOW 

Some  other  relations  between  adjectives  include: 

PREDICATE  of  HIGHER  is  HIGH 
COMPARATIVE  of  HIGHEST  is  HIGHER 
SUPERLATIVE  of  HIGHER  Is  HIGHEST 

The  IDENTITY  property  gives  the  identity  element  of  a  specified  operator; 

IDENTITY  of  AND  is  T 
IDENTITY  of  D*  is  INCREASING 


§1.3 .2.2.  Semantic  Network 
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Finally,  the  ADD  property  encodes  information  about  homomorphisms.  A  homomorphism  is  a 
function  f  such  that  (f  (4-  x  y))  =  (+’  (f  x)  (f  y))  where  +  and  +  ’  represent  addition-like  operators 
in  the  domain  and  range  of  f,  respectively.  Information  about  homomorphisms  could  be 
straightforwardly  encoded  as  a  ternary  relation  (H  f  +  +’)•  Rather  than  implementing  a  special 
mechanism  to  handle  ternary  relations,  I  exploited  the  fact  that  f  uniquely  determined  +'  for  the  few 
instances  of  the  relation  H  used  in  the  derivations.  The  ADD  property  maps  f  to  +',  eg.,  the 
homomorphic  identity  (in  e  (union  SI ...  Sn))  =  (or  [in  c  SI] ...  [in  e  Sn])  is  encoded  as 
ADD  of  IN  Is  OR 

The  semantic  relations  encoded  in  FOO  are  listed  in  Appendix  C.2. 

1.3.3.  Domain-specific  Rules 

FOO  uses  a  few  domain-specific  “fact  rules"  to  simulate  unimplemented  mechanisms.  Typically,  a 
fact  about  a  concept  is  represented  as  a  rule  in  the  absence  of  a  definition  for  the  concept.  For 
example,  the  fact  that  the  number  of  cards  in  each  suit  is  13  is  represented  as 

RULE376:  (#  (cards- in-suit  s)) ->  13 

This  is  easier  than  representing  the  concept  of  set  cardinality  (denoted  by  "#”)  as  a  definition  of 
the  form 

tf  =  (LAMBDA  (S)  <what  goes  here?>) 

Moreover,  it  is  not  clear  that  such  a  definition  would  provide  an  efficient  way  to  compute  the 
number  of  cards  in  a  suit. 

1. 3.3.1  Simulated  Types 

Some  fact  rules  simulate  a  type  mechanism: 

RULE62:  (in  QS  (cards))  ->  T  -  QS  is  a  card 

RULE173:  (in  ME  (players))  ->1  -  ME’  is  a  player 

RULE197:  (domain  suit-of)  ->  (cards)  --  argument  of  suit-of  is  a  card 

RULE363 :  (subset  (cards-played)  (cards))  ->  T  --  (cards- played)  is  a  set  of  cards 

RULE365:  (in  (leader)  (players))  ->  T  -  (leader)  is  a  player 
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1. 3.3.2  Simulated  Partitioning 

Some  rules  simulate  a  NFTL-like  scheme  [Fahlman  79]  for  encoding  information  about  mutually 
exclusive  subsets  or  cases: 

RULE163:  (range  loc)  ->  (partition  [hands  (players)]  [piles  (players)]  [set  deck  pot  hole]) 
RULE299:  (not  (or  higher  =))  ->  lower  --  HIGHER  and  LOWER  are  domain- specific 

1. 3.3.3  Simulated  Property  Retrieval 

Other  rules  simulate  a  mechanism  for  retrieving  properties  of  objects: 

RULE2:  (suit-ofQS)  ->S 
RULE376:  (#  (cards-in-suit  s)) ->  13 

1.3.3.4  Simulated  Deductions 

Finally,  several  rules  represent  facts  FOO  already  has  enough  knowledge  to  prove,  or  might  be  able 
to  deduce  from  a  complete  description  of  the  task: 

RULE1:  (has  (owner-of c)  c) ->  T 

RULF.61:  (actions-of  p)  ->  (play-card  p)  if  (trick- in-progress)  --  actions-of  -  legal  moves 
RULE146:  (=  (player-ofc)  p) ->  (=  (card-ofp)c) 

RULEI80:  (at  card  deck)  ->  nil  if  (round-progressing) 

RULE228:  (legal  p  c)  ->  T  if ( =  c  (card-of p)) 

RULE279:  (change  cantus-1)  ->  (list  (next  note)) 

RULE357:  (before  (current  round-in- progress)  (at  card  (pile  p)))  ->  nil 

RULE372:  (before  (current  round-in-progress)  (in-pot  c))  ->  nil 

RULE373:  (ate  ho..)  ->  nil  by  assumption  --  instance  of  “assume  C  is  false  if  unlikely " 

These  19  rules  arc  the  only  fact  rules  used  in  the  derivations.  The  rest  of  foo’s  rules  arc  general. 


§  1.4.  Knowledge  Used  in  Operationalization 
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1.4.  Knowledge  Used  in  Operationalization 

A  view  of  operationalization  that  emerges  from  the  derivations  can  be  summarized  (with  apologies 
to  Edison)  by  the  equation 

Operationalization  =  2%  Inspiration  +  98%  Perspiration 
In  this  case 

Inspiration  =  general  ideas  about  operationalization 

Perspiration  =  domain  knowledge  and  analysis  required  to  apply  the  general  ideas 

Some  general  operationalization  methods  used  in  the  derivations  include: 

Reformulate  a  goal  as  an  evaluable  predicate  on  a  choice  variable.  (§4,3.1.2) 

Use  heuristic  search  to  evaluate  a  predicate  on  a  sequence  of  choices  (§3) 

Find  an  evaluable  necessary  or  sufficient  condition  for  an  unevaluable  predicate.  (§2.6) 

Evaluate  a  predicate  on  a  set  in  terms  of  the  probability  that  it’s  disjoint  with  another  set.  (§2.3) 
Approximate  an  expression  as  an  increasing  or  decreasing  Junction  of  some  quantity.  (§2.8) 

Use  the  value  of  a  predicate  from  an  earlier  situation  if  it  can  7  have  changed  since  then.  (§2.4) 


1.5.  Analysis  Techniques 

Applying  these  methods  to  a  given  problem  typically  requires  analysis  based  on  domain 
knowledge.  A  variety  of  analysis  techniques  (§5)  are  illustrated  in  the  following  excerpts  from 
DERIV6,  which  also  serve  to  introduce  notation  used  in  later  examples.  (The  complete  derivation  is 
43  steps  long.)  In  this  derivation,  the  advice  "avoid  taking  points”  is  operationalized  as  “make  my 
card  low”  by  applying  the  general  strategy 

Reformulate  a  goal  as  an  evaluable  predicate  on  a  choice  variable. 

The  initial  advice  is  encoded  as 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

This  actually  means  “avoid  taking  points  during  the  trick."  The  added  specification  simplifies  the 
operationalization  problem  by  disambiguating  the  advice,  since  “avoid  taking  points"  is  ambiguous 
with  respect  to  the  time  interval  over  which  the  act  of  taking  points  is  to  be  avoided. 
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The  initial  expression  is  non-operational  for  the  assumed  runtime  mechanism  because  it’s  not 
expressed  in  terms  of  that  mechanism’s  built-in  capabilities,  Le .,  it  doesn't  specify  what  card  to  play  in 
a  given  situation  in  order  to  avoid  taking  points.  To  operationalize  the  advice,  it  is  necessary  to  apply 
knowledge  about  the  concepts  in  terms  of  which  the  advice  is  expressed.  These  concepts  arc  defined 
as  follows: 

Avoid  an  event  over  some  period  means  try  not  to  let  the  event  occur  during  the  period. 

Take  points  means  take  a  point  card. 

A  trick  is  a  scenario  in  which  each  player  plays  a  card  and  then  the  winner  takes  them  all. 

These  definitions  are  encoded  in  Foo  as  follows: 

AVOID  *  (LAMBDA  (EVENT  PERIOD) 

(ACHIEVE  (NOT  (DURING  PERIOD  EVENT)))) 

TAKE-POINTS  =  (LAMBDA  (PLAYER) 

(FOR-SOME  C  (POINT-CARDS)  (TAKE  PLAYER  C))) 

TRICK  *  (LAMBDA  () 

(SCENARIO 

(EACH  P  (PLAYERS)  (PLAY-CARD  P)) 

(TAKE-TRICK  (TRICK-WINNER)))) 


1.5.1.  Elaboration 

First  the  problem  is  elaborated  (§  5.8.2)  by  expanding  the  definitions  of  AVOID  and  TRICK : 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

6:2-3  ---  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (NOT  (DURING  (SCENARIO 

(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME)))) 

The  notation  “6:2-3”  refers  to  steps  2  through  3  in  the  derivation  DHRIV6.  The  notation 
“ —  [ELABORATE  by  RULE124]  — >”  between  the  two  expressions  indicates  that  the  second 
expression  is  the  result  of  elaborating  the  first,  and  that  this  transformation  is  effected  by  RU1.F.124, 
shown  below: 

RULE124:  (f  e1 ...  cn)  ->  c\  where  f  is  defined  as  (lambda  (xt ...  xfl)  e) 
and  c’  is  the  result  of  substituting  Cj ...  en  for  Xj ...  xn  throughout  c 


§1.5.2.  Case  Analysis 
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1.5.2.  Case  Analysis 


The  resulting  expression  is  non-operational  since  it  depends  on  the  outcome  of  the  trick,  which  is 
generally  unforeseeable  at  the  time  player  ME  (foo's  card-playing  persona)  must  choose  a  card 
consistent  with  the  advice.  Thus  the  expression  must  be  analyzed  to  determine  which  properties  of 
the  card  player  ME  plays  may  enable  it  to  avoid  taking  points.  Case  analysis  (§5.7.1)  shows  that  player 
ME  can  only  take  points  by  winning  the  trick: 

(ACHIEVE  (NOT  (DURING  (SCENARIO 

(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME))))) 

6:4  ---  [DISTRIBUTE  by  RULE284]  ---> 

(ACHIEVE  (NOT  (OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-POINTS  ME)] 

[DURING  (TAKE-TRICK  (TRICK-WINNER)) 

(TAKE-POINTS  ME)]))) 


This  transformation  is  performed  by 

RULE284:  (f...  (+  ...  en) ...)  -><+*  (f ...  et ...) ...  (f ...  en ...» 

where  +  is  an  addition-like  operator  over  the  domain  of  f,  +’  is  the  corresponding  operator 
over  the  range  of  f,  and  (lambda  (x)  (f ...  x  ...))  is  a  homomorphism4  with  respect  to  +  and  +’ 

Here  f  =  DURING.  FOO  identifies  g  =  (LAMBDA  (X)  (DURING  X  (TAKE-POINTS  ME)))  as  a 
homomorphism  and  +  =  SCENARIO  as  an  addition-like  operator  by  searching  through  an  is-a 
hierarchy  (§1.3.2. 1)  and  finding  paths  from  DURING  to  HOMOMORPHISM  and  from  SCENARIO  to  JOIN. 
It  retrieves  +  ’  =  OR  from  a  semantic  network  containing  the  attribute-value  relation 
ADO  of  SCENARIO  Is  OR  (§  1.3.2.2). 

Note  that  RULE284  is  applied  to  the  sub-expression  ( DURING  . . . )  of  the  overall  problem 

(ACHIEVE  (NOT  (OURING  (SCENARIO 

(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME))))) 

This  is  indicated  by  indenting  the  arrow  representing  step  6:4  so  that  it  lines  up  under  die 
beginning  of  the  transformed  sub-expression.  The  same  convention  is  used  throughout  the 
dissertation  where  feasible.  For  simplicity,  the  context  surrounding  a  transformed  sub-expression  is 
often  abbreviated  or  omitted  when  displaying  the  transformation. 

4 

A  function  g  is  a  homomorphism  with  respect  to  additive  operators  4-  and  f  ’  if  g(x  +  y)  =  g(x)  +■  ‘  g(y). 


34 


§1.  Introduction 


1.5.3.  Intersection  Search 

At  this  point,  “taking  points”  has  been  split  into  two  cases:  taking  points  during  the  part  of  the 
trick  when  cards  are  played,  and  taking  points  when  the  winner  takes  the  trick.  The  first  case  is 
eliminated  based  on  the  fact  that  a  TAKE-POINTS  event  can’t  occur  during  a  sequence  consisting 
exclusively  of  PLAY-CARD  events: 

(DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)) 

6:5  — -  [COMPUTE  by  RULE57]  — > 

NIL 

This  is  accomplished  by 

RULE57:  (during  s  e)  ->  nil  if  s  and  e  have  no  common  sub-events 

FOO  tests  RULE57’s  condition  by  performing  an  intersection  search  through  the  knowledge  base  of 
defined  concepts  (§5.6)  for  a  common  sub-event  of  s  and  e.  Here  e  =  (TAKE-POINTS  ME)  and  s  = 
(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)). 

The  sub-events  of  an  event  include  the  action  concepts  used  to  define  iL  the  lower-level  concepts 
in  terms  of  which  those  actions  are  defined,  and  so  forth,  down  to  but  not  including  primitive 
concepts  like  MOVE.  In  the  current  example,  s  =  (EACH  Pt  (PLAYERS)  (PLAY-CARD  Pl)),soone 
sub-event  of  s  is  the  action  concept  PLAY-CARD.  This  concept  is  defined  by 

PLAY-CARD  *  (LAMBDA  (P)  (CHOOSE  Cl  (LEGALCARDS  P)  (PLAY  P  Cl))) 

That  is,  PLAY-CARD  refers  to  the  action  of  choosing  a  legal  card  and  playing  it.  Thus  PLAY  is  a  sub- 
event  of  PLAY-CA"0  and  hence  of  s.  Similarly,  a  sub-event  of  e  =  (TAKE-POINTS  ME)  is 
TAKE-POINTS,  defined  by 

TAKE-POINTS  ■  (LAMBDA  (P)  (FOR-SOME  Cl  (POINT-CARDS)  (TAKE  P  Cl))) 

This  definition  says  that  taking  points  means  taking  some  point  card,  take  is  a  sub-event  of 
take-points.  Thus  the  sub-events  of  s  are  play-card  and  PLAY,  while  the  sub-events  of  c  are 
TAKE -POINTS  and  TAKE.  Since  these  two  sets  arc  disjoint,  RULF.57’s  condition  is  satisfied. 
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1.5.4.  Partial  Matching 


The  concepts  TAKE-TRICK  and  TAKE-POINTS  have  the  common  sub-event  TAKE.  The  problem  is 

elaborated  by  plugging  in  their  definitions  and  restructured (§5.10)  by  extracting  quantifiers: 

(DURING  (TAKE-TRICK  (TRICK-WINNER)) 

(TAKE -POINTS  ME)) 

6:7-10  —  [ELABORATE  by  RULE124 ,  restructure]  — > 

(EXISTS  C3  (CAROS-PLAYEO) 

(EXISTS  Cl  (POINT-CARDS) 

(DURING  (TAKE  (TRICK-WINNER)  C3) 

(TAKE  ME  Cl)))) 


FOO  has  no  definition  for  the  DURING  predicate,  but  knows  it’s  reflexive.  This  guarantees  that  it  is 
logically  sound  to  partial-match(l  HKE  (TRICK-WINNER)  C3)  against  (TAKE  ME  Cl)  (§5.3)  using 

RULE43:  (R  (fej ...  en)(fej\..  en’))->(and{=  e1e1 ’)...[=  enen’])  if  R  is  reflexive 


RULE43  is  sound  because  its  right  side  logically  implies  its  left  side  if  R  is  reflexive.  Here  R  = 

DURING  andf  =  TAKE.  Applying  RULE43  reduces  the  expression  to  a  conjunction  of  equalities: 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(DURING  (TAKE  (TRICK-WINNER)  C3) 

(TAKE  ME  Cl)))) 

6:11  ---  [REDUCE  by  RULE43]  — > 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(AND  [=  (TRICK-WINNER)  ME] 

[»  C3  Cl]))) 


The  quantifier  variable  Cl  is  eliminated  by  applying  some  simplification  rules  (§5.2): 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(AND  [*  (TRICK-WINNER)  ME] 

[■  C3  Cl]))) 

6:12-13  —  [SIMPLIFY  by  RULE59 ,  RULE108]  ---> 

(ANO  [*  (TRICK-WINNER)  ME] 

[EXISTS  C3  (CARDS-PLAYED)  (HAS-POINTS  C3) ]) 
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1.5.5.  Recognizing  Known  Concepts 

The  second  conjunct  is  now  recognized (§5.8.3)  as  a  known  concept: 

(EXISTS  C3  (CARDS-PLAYED)  (HAS-POINTS  C3)) 

6:21-22  —  [RECOGNIZE  by  RULE123]  ---> 

(TRICK-HAS-POINTS) 

This  is  accomplished  by 

RULE123:  e  ->(fe1 ...  eQ)  if  f  is  defined  as  (lambda  (Xj ...  xn)  <body>) 
and  c  is  the  result  of  substituting  e: ...  en  for  x: ...  xn  throughout  <body> 

Recognizing  a  known  concept  could  enable  application  of  previously  learned  knowledge  about  it, 
e.g.,  ways  to  predict  the  likelihood  that  a  trick  will  have  points  (§6.3.1). 

1.5.6.  Approximating  an  Expression  as  a  Function  of  Available  Data 

Taking  points  has  now  been  narrowed  down  to  winning  a  trick  that  has  points.  Some  analysis  of 

the  definition  of  TRICK-WINNER  leads  to  the  expression 

(ACHIEVE  (NOT  (AND  [*  (TRICK-WINNER)  ME] 

[TRICK-HAS-POINTS]))) 

6:23-42  —  [by  analysis]  - > 

(ACHIEVE  (=>  [AND  [IN-SUIT-LED  (CARO-OF  ME)] 

[TRICK-HAS-POINTS]] 

[LOWER  (CARD-OF  ME) 

(FINO-ELT  (CARDS-PLAYED- IN-SUIT-LED))])) 

This  means  “if  you’re  following  suit  in  a  trick  with  points,  try  to  underplay  some  other  card  played 
in  the  suit  led."  Since  (CARDS-PLAYED-IN-SUIT-LED)  is  generally  unknown  when  player  ME 
chooses  (CARD-OF  ME),  the  expression  is  not  operational.  Dependence  on  the  unknown  set  is 
eliminated  by  using  the  unary  predicate  LOW  to  approximate  the  binary  relation  LOWER  (§2.8.7): 

(LOWER  (CARO-OF  ME) 

(FINO-ELT  (CARDS-PLAYED- IN-SUIT -LEO) ) ) 

6:43  ---  [REDUCE  by  RULE154]  — > 

(LOW  (CARD-OF  ME)) 

This  transformation  is  not  logically  sound,  but  is  certainly  useful.  It  is  effected  by 
RULE154:  (R  c1  e.,)  ->  (P  e^  where  R  is  the  comparative  form  of  predicate  P 
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Here  R  =  LOWER.  FOO  finds  P  =  LOW  by  retrieving  the  semantic  relation 

PREDICATE  of  LOWER  Is  LOW 

The  resulting  expression  is  a  predicate  on  the  choice  variable  (  CARD-of  ME ) : 

(ACHIEVE  (»>  [AND  [IN-SUIT-LED  (CARD-OF  ME)] 

[TRICK-HAS-POINTS]] 

[LOW  (CARD-OF  ME)])) 

If  LOW  is  treated  as  a  fuzzy  predicate  [Zadeh  79).  the  expression  is  likewise  a  fuzzy  predicate,  and 
can  be  used  to  order  potential  candidates  for  (CARD-OF  ME).  The  expression  is  evaluable  if  the 
runtime  mechanism  can  evaluate  (TRICK-HAS-POINTS).  This  is  not  possible  in  general  since  it  is 
typically  impossible  to  predict  at  card-choosing  time  whether  the  trick  will  have  points.  One  way  to 
get  around  this  is  to  assume  the  trick  will  have  points  in  the  absence  of  knowledge  to  the  contrary. 
This  could  be  done  by  applying 

RULE318:  P  ->  (possible  P).  where  (possible  P)  is  true  unless  P  is  known  to  be  false. 

RULE318  is  based  on  three- valued  logic  (§2.6.3).  Note  that  (possible  P)  is  evaluable  even  when  P 
is  noL  Applying  RULE318  produces  the  expression 

(ACHIEVE  (=*>  [AND  [IN-SUIT-LED  (CARD-OF  ME)] 

[POSSIBLE  (TRICK-HAS-POINTS)]] 

[LOW  (CARO-OF  ME)])) 

This  expression  represents  the  plan  “If  you’re  following  suit  in  a  trick  that  may  have  points,  make 
your  card  low.”  This  plan  is  an  operational  approximation  of  the  advice  “avoid  taking  points”:  it  is 
not  always  effective,  but  it  is  always  applicable  (assuming  that  player  ME  has  a  low  card,  or  that  “low” 
is  interpreted  as  “lowest  available"). 


1.6.  Operationalization  Scenarios 

The  example  just  presented  illustrates  a  common  scenario  in  the  operationalization  process,  shown 
in  Figure  1-2:  using  analysis  techniques  (§5)  and  domain  knowledge  (§6),  the  expression  is 
reformulated  (§4)  as  a  computable  function  of  available  information,  such  as  choice  variables  and 
observable  data. 

A  more  complex  operationalization  scenario  is  shown  in  Figure  1-3:  the  expression  is  mapped  to  a 
known  operationalization  method  (§2)  whose  application  produces  an  operational  expression,  or 
something  closer  to  it.  For  example,  the  advice  “avoid  taking  points”  can  be  mapped  onto  the 
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Figure  1*2:  Operationalization  by  reformulation 
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Figure  i-3:  Operationalization  by  applying  a  method 

heuristic  search  method  (§3),  producing  a  procedure  that  searches  through  the  space  of  possible  card 
sequences  for  the  trick  to  see  if  any  of  them  cause  player  ME  to  take  points,  i.e.,  contain  points  and 
have  player  ME’s  card  as  the  highest  in  the  suit  led. 

The  scenario  depicted  in  Figure  1-3  can  be  elaborated  by  identifying  some  common  stages  in  the 
application  of  an  operationalization  method: 

1.  Reformulate  an  expression  until  it’s  possible  to 

2.  Recognize  that  the  method  is  applicable  and  decide  to  apply  it,  so 

3.  Reformulate  the  expression  to  match  the  method  problem  statement  and 

4.  Fill  in  additional  information  required  by  the  method;  then 

5.  Refine  the  instantiated  method  by  applying  additional  domain  knowledge. 

At  this  point  the  instantiated  method  is  ready  for  execution  or  application  of  other  methods.  Not 
all  of  these  stages  are  explicit  and  separate  every  time  a  method  is  applied,  but  when  they  do  occur, 
they  tend  to  occur  in  the  order  described. 

DERIV9  clearly  illustrates  these  stages.  In  this  derivation,  the  disjoint  subsets  method  (§2.3)  is  used 
to  solve  the  operationalization  problem  (EVAL  (VOID  PO  SO))  by  deriving  a  formula  to  estimate 
die  probability  that  a  player  PO  is  void  in  a  suit  SO.  The  key  idea  of  the  method  is  to  apply  a  general 
formula  for  the  probability  that  two  randomly  selected  subsets  S  and  S'  of  a  universe  U  will  be 
disjoint.  Since  the  formula  depends  only  on  the  sizes  of  S,  S’,  and  U.  this  method  can  be  useful  for 
evaluating  predicates  on  unknown  sets. 
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The  initial  expression  is  reformulated  by  elaboration: 

(VOID  PO  SO) 

9:1  ---  [ELABORATE  by  RULE124]  ---> 

(NOT  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))) 


RULE189  recognizes  this  expression  as  a  predicate  on  the  unknown  set  (CARDS-  IN-HAND  PO)  and 

consequently  decides  to  apply  the  disjoint  subsets  method.  This  requires  reformulating  the  expression 

in  terms  of  disjoint  subsets  in  order  to  match  the  method's  problem  statement.  In  particular,  it  is 

necessary  to  solve  for  S,  S',  and  U.  This  involves  considerable  analysis: 

(NOT  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))) 

9:2-21  —  [by  RULE189 ,  analysis]  — > 

(PR-DISJOINT  (CARDS-IN-HAND  PO) 

(CAROS-IN-SUIT  SO) 

(COMMON-SUPERSET  (CARDS-IN-HAND  PO) 

(CARDS-IN-SUIT  SO))) 


This  expression  denotes  the  probability  that  the  cards  held  by  player  PO  and  the  cards  in  suit  SO  are 

disjoint  subsets  of  an  unspecified  common  superset  The  next  step  is  to  fill  in  this  information 

unspecified  in  the  original  problem  but  required  by  the  method: 

(COMMON-SUPERSET  (CARDS-IN-HAND  PO) 

(CARDS-IN-SUIT  SO)) 

9:23-25  —  [by  intersection  search]  — > 

(CARDS) 


The  resulting  solution  is  refined  by  considering  only  those  cards  satisfying  some  predicate  satisfied 
by  every  element  of  (CARDS-IN-HAND  PO).  A  knowlcgc  base  search  finds  the  predicate  OUT;  a  card 
is  “out”  if  some  opponent  has  it  Verifying  that  all  cards  held  by  an  opponent  PO  are  out  involves 
some  analysis: 


(PR-DISJOINT  (CARDS-IN-HAND  PO) 
(CARDS-IN-SUIT  SO) 

(CARDS)) 

9:27-39  —  [REFINE  by  RULEZOO,  analysis]  — > 
(PR-DISJOINT  (CARDS-IN-HAND  PO) 

( CARDS -OUT -IN- SUIT  SO) 
(CARDS -OUT)) 


The  method  is  applied  by  using  a  formula  for  the  probability  that  two  randomly  chosen  subsets  of  a 
set  are  disjoint: 
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(PR-DISJOINT  (CARDS-IN-HAND  PO) 

(CARDS -OUT -IN- SUIT  SO) 
(CARDS-OUT)) 

9:40-43  ---  [APPLY  by  RULE124 ,  analysis]  — > 
(PR-DISJOINT-FORMULA  (0CARDS-IN-HAND  PO) 

(#C ARDS -OUT -IN- SUIT  SO) 
(#CARDS-OUT) ) 


Given  a  procedure  for  computing  PR-OISJOINT-FORMULA  and  methods  for  evaluating  its  three 
arguments,  this  expression  is  operational  and  can  be  evaluated  at  runtime. 


An  alternative  to  evaluating  the  expression  is  to  analyze  its  Junctional  dependence  on  one  of  its 
arguments  (§2.8): 

(EVAL  (PR-DISJOINT-FORMULA  ( #CARDS-IN-HAND  PO) 

(#C ARDS -OUT- IN- SUIT  SO) 

( 0CARDS-OUT ) ) ) 

9:44-57  ---  [by  RULE202,  analysis]  ---> 

(FUNCTION-OF  ( #CARDS-0UT- IN-SUIT  SO)  DECREASING) 


This  expression  means  “a  decreasing  function  of  the  number  of  cards  out  in  suit  SO.”  It  can  be 
used  to  order  the  suits  according  to  the  probability  of  a  void  in  them,  without  actually  computing  the 
probabilities  (§2.8.3).  This  approximation  technique  is  especially  useful  for  expressions  that  cost  too 
much  to  evaluate  or  contain  unknown  terms. 


Some  of  the  stages  in  applying  an  operationalization  method  involve  a  considerable  amount  of 

logical  analysis  or  “theorem-proving”.  For  instance,  reformulating  “avoid  taking  points”  as  a 

heuristic  search  problem  requires  figuring  out  the  sequence  of  choice  points  in  a  trick  in  order  to 

formulate  the  search  space.  Refining  the  search  involves  finding  tests  that  predict  whether  a  partial 

path  through  this  space  can  be  extended  into  a  scenario  in  which  points  arc  taken;  tins  requires  the 

ability  to  analyze  logical  relationships  between  partial  and  total  paths.  For  example,  if 

CARDS-PLAYEDl  is  a  subsequence  of  the  complete  sequence  (CARDS-PLAYED)  of  cards  played  in  the 

trick,  these  two  implications  hold: 

(AND  [IN  (CARD-OF  ME)  CARDS-PLAYEDl] 

[=  (CARD-OF  ME)  (HIGHEST-IN-SUIT-LED  (CARDS-PLAYED))])  => 

(=  (CARD-OF  ME)  (HIGHEST-IN-SUIT-LED  CARDS-PLAYEDl)) 

(HAVE-POINTS  CARDS-PLAYEDl)  =>> 

(HAVE-POINTS  (CARDS-PLAYED)) 

The  first  implication  guarantees  that  when  searching  the  space  of  potential  scenarios  (card 
sequences)  for  the  trick  to  sec  if  any  cause  player  ME  to  take  points,  it  is  safe  to  ignore  any  sequences 
containing  both  player  ME’s  card  and  a  higher  card  in  the  suit  led.  The  second  implication  suggests 
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that  a  scenario  in  which  player  ME  takes  points  might  be  found  more  quickly  by  giving  priority  to 
extending  partial  sequences  that  already  have  points,  since  dieir  extensions  will  also  have  points. 
Deriving  these  implications  involves  a  substantial  amount  of  analysis. 

In  short,  applying  an  operationalization  method  requires  domain  knowledge  and  analysis  in 
addition  to  knowledge  about  the  method. 

1.7.  Using  the  Heuristic  Search  Method 

AI  researchers  draw  upon  a  repertoire  of  sophisticated  operationalization  methods,  but  relatively 
little  has  been  accomplished  towards  getting  computers  to  apply  them  automatically.  Mechanizing 
this  process  raises  several  issues: 

How  to  represent  a  general  method  so  that  it  can  be  reasoned  about  mechanically 
How  to  map  a  particular  problem  onto  the  general  problem  statement  for  the  method 
How  to  till  in  information  requited  by  the  method  but  not  explicit  in  die  original  problem 
How  to  use  additional  knowledge  about  the  problem  domain  to  improve  the  solution 

The  dissertation  explores  these  questions  for  the  heuristic  search  method  (“HSM”)  (§3).  It 
presents  some  concrete  answers  in  the  form  of  a  schema  representation  of  HSM  and  some  rules  that 
operate  on  it.  In  DER1V2,  these  rules  are  used  to  operationalize  the  advice  “avoid  taking  points."  As 
a  test  of  generality,  the  same  schema  and  rules  are  used  in  DERIV13  to  operationalize  a  simple  music 
composition  task. 

1.7.1.  A  Generic  Heuristic  Search  Procedure 

Viewed  abstractly,  the  purpose  of  heuristic  search  is  to 
Find  a  sequence  of  choices  satisfying  a  given  criterion. 

'Hie  problem  space  for  heuristic  search  is  a  set  of  partial  sequences  (paths).  The  search  proceeds  by 
selecting  a  path  from  the  space,  extending  it  by  one  of  the  permissible  choices,  and  testing  it  to  sec  if 
it  satisfies  the  search  criterion.  This  cycle  repeats  until  a  solution  is  found  or  the  problem  space  is 
exhausted. 

The  components  of  FOO’s  HSM  schema  include  the  set  of  alternatives  at  each  choice  point  and  the 
search  criterion  expressed  as  a  function  of  the  choice  sequence.  Instantiating  these  components 
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suffices  to  formulate  an  executable  (albeit  inefficient)  search.  For  “avoid  taking  points,"  a  path  is  a 
card  sequence  for  the  trick;  the  choice  set  at  each  point  consists  of  the  legal  cards  the  player  at  that 
point  might  have,  according  to  the  information  available  to  player  ME;  and  the  search  criterion  tests 
whether  a  given  card  sequence  causes  player  ME  to  take  points,  i.e..  whether  player  ME’s  card  is  the 
highest  in  the  suit  led  and  the  sequence  contains  one  or  more  point  cards. 

1.7.2.  Refining  the  Search 

This  incfficent  search  can  be  refined  by  reorganizing  it  so  that  constraints  arc  applied  as  early  as 
possible.  In  DERIV2,  for  example,  the  search  is  refined  to  generate  only  sequences  in  which  player 
ME  wins  the  trick,  and  to  look  first  for  sequences  containing  point  cards,  so  as  to  quickly  find  a 
scenario  in  which  player  ME  takes  points.  The  schematic  representation  of  HSM  corresponds  to  a  data 
flow  graph  containing  various  components  that  order  or  reject  paths  and  alternatives.  The  search  is 
refined  by  rules  that  transfer  constraints  from  one  such  component  to  another. 

1.7.3.  Generality  of  the  HSM  Representation 

The  generality  of  the  HSM  schema  (and  the  rules  for  instantiating  and  refining  it)  was  tested  on 
the  music  composition  task  described  earlier  (§1.2.4).  The  HSM  rules  developed  to  handle  the  Hearts 
example  were  either  directly  applicable  to  the  music  example  or  very  similar  to  ones  that  were,  and 
moreover  led  to  some  of  the  same  design  decisions  embodied  in  a  previous  music  composition 
program  [Meehan  72[. 

1.8.  Overview 

The  next  several  chapters  describe  knowledge  used  in  operationalization.  (§2)  presents  a  repertoire 
of  operationalization  strategies  and  illustrates  their  use  in  evaluation  and  planning.  (§3)  shows  how 
two  problems  from  different  domains  are  operationalized  as  heuristic  search  procedures,  using  many 
of  the  same  general  rules  about  the  heuristic  search  method.  (§4)  discusses  the  process  --  central  to 
operationalization  ~  of  reformulating  a  problem  in  terms  of  the  capabilities  of  the  task  agent  or  the 
requirements  of  a  method.  (§5)  describes  the  methods  used  for  analysis ;  these  provide  the  inferential 
power  required  to  apply  general  operationalization  methods  to  specific  problems.  (§6)  examines  the 
various  ways  in  which  general  and  domain-specific  conceptual  knowledge  comes  into  play. 

Next,  (§7)  sketches  an  approach  for  automatic  problem-solving  in  the  operationalization  problem 
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space  based  on  means-end  analysis,  and  presents  a  simulated  example  of  its  operation.  (§8)  discusses 
areas  for  further  research.  (§9)  summarizes  the  contributions  of  the  dissertation  in  light  of  previous 
research.  Appendix  A  describes  the  hearts  and  music  tasks.  Appendix  B  lists  FOO’s  transformation 
rules  in  a  machine-generated  notation  and  describes  FOO’s  rule  interpreter.  Appendix  C  lists  the 
concept  properties  and  definitions  in  FOO's  knowledge  base.  Appendix  D  presents  the  complete 
derivations,  and  Appendix  E  analyzes  the  operationally  of  the  derived  expressions. 
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Chapter  2 

Operationalization  Methods 

This  chapter  presents  several  methods  used  in  FOO  to  operationalize  expressions.  These  include: 

1.  The  pigeon-hole  principle.  (§2.2) 

2.  A  probabilistic  formula  for  estimating  whether  two  subsets  are  disjoint.  (§2.3) 

3.  Some  rules  for  expressing  present  conditions  in  terms  of  past  events.  (§2.4) 

4.  A  method  for  depleting  a  set.  (§2.5) 

5.  A  technique  for  finding  necessary  or  sufficient  conditions  for  a  given  predicate.  (§2.6) 

6.  A  model  of  choice.  (§2.7) 

7.  A  calculus  for  approximating  an  expression  as  a  function  of  a  known  quantity.  (§2.8) 

8.  The  use  of  simplifying  assumptions  in  planning  and  evaluation.  (§2.9) 

9.  A  strategy  for  integrating  interdependent  constraints.  (§2.10) 

10.  A  representation  shift  for  treating  a  problem  as  a  goal  to  be  achieved  over  time.  (§2.11) 

11.  A  way  to  simplify  a  problem  by  binding  one  of  its  parameters  before  solving  it.  (§2.12) 

These  methods  form  the  kernels  of  the  derivations;  they  appear  simple  to  the  point  of  triviality, 
but  are  the  key  to  solving  a  variety  of  problems,  given  an  analysis  engine  adequate  lo  reformulate  the 
problem  in  terms  of  the  method  and  then  solve  the  subproblems  generated  (explicitly  or  implicitly)  by  the 
method.  As  Newell  has  observed. 

In  general,  in  all  design  there  is  a  key  idea,  which  need  not  be  very  deep,  but  which  changes  an 
open  problem  of  discovery  to  a  closed  task  of  problem  solving.5 

Each  section  of  this  chapter  presents  one  of  these  methods,  shows  how  it  can  be  applied 
mechanistically  to  one  or  more  problems,  and  describes  its  implementation  as  a  transformation  rule 
or  collection  of  rules. 
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The  methods  listed  above  represent  a  small,  arbitrarily  chosen  set  of  points  in  the  space  of 
operationalization  methods  one  could  describe.  Each  method  is  formulated  in  a  general  fashion,  Le., 
without  reference  to  terms  specific  to  card  games  or  music.  This  generality  of  expression  gives  some 
hope  for  generality  of  application,  Le.,  suggests  that  the  methods  might  in  fact  apply  not  only  to  the 
problems  used  to  illustrate  them,  but  to  other  problems  in  other  task  domains.  In  a  few  cases,  a 
method  is  explicitly  applied  to  more  than  one  problem. 


2.1.  Taxonomy  of  Operationalization  Methods 

FOO’s  operationalization  methods  can  be  classified  according  to  some  genera!  criteria: 

1.  Purpose  -  generate  a  procedure  to  evaluate  an  expression  or  achieve  a  goal 

2.  Scope  --  how  often  can  the  procedure  be  executed? 

3.  Accuracy  --  how  often  docs  executing  the  procedure  produce  the  desired  result? 

There  can  be  a  tradeoff  between  scope  and  accuracy  for  a  given  method.  The  scope  of  a  procedure 
can  be  defined  as  the  proportion  of  situations  in  which  it  can  be  executed.  The  accuracy  of  a 
procedure  can  be  defined  as  the  correlation  between  its  result  and  the  correct  answer,  summed  over 
ail  the  situations  in  which  it  can  be  executed.  This  definition  allows  procedures  that  return  results 
expressed  as  probabilities,  e.g..  “player  X  is  void  with  probability  Y”  or  "play  card  X  to  avoid  taking 
points  with  probability  Y.”  The  accuracy  of  such  a  procedure  can  be  increased,  at  the  cost  of 
decreasing  its  scope,  by  only  using  the  result  in  situations  where  the  probability  exceeds  some 
threshold. 

The  criteria  of  purpose,  scope,  and  accuracy  define  a  taxonomy  into  which  I'OO’s  methods  fit: 

1.  Methods  for  evaluating  an  expression 

a.  Procedures  that  produce  an  exact  result 

i.  Procedures  that  always  produce  a  result  (assuming  their  inputs  are  available) 

Pigeon-hole  principle  (§2.2) 

Historical  reasoning  (§2.4) 

Heuristic  search  (§3) 

ii.  Procedures  that  sometimes  produce  a  result 


Check  a  necessary  or  sufficient  condition  (§2.6) 

Make  a  simplifying  assumption  that  restricts  the  scope  of 
applicability  (§2.9.2.1) 
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iii.  Procedures  that  produce  an  approximate  result 

Apply  formula  for  probability  of  disjoint  subsets  (§2.3) 

Functional  dependence  analysis  (§2.8) 

Use  an  untested  simplifying  assumption  (§2.9.3) 

Predict  others’  choices  pessimistically  (§2.7.3) 

2.  Methods  for  achieving  a  goal 

a.  Sound  methods  (introduce  no  errors)  -  execution  of  plan  (when  feasible)  will  achieve 
goal 

Set  depletion  (§2.5) 

Find  a  sufficient  condition  and  achieve  it  (§2.6) 

Restrict  a  choice  to  satisfy  the  goal  (§2.7.1) 

Combine  multiple  goals  (§2.10) 

Rules  for  achieving  goals  over  time  (§2.11) 

b.  Heuristic  methods  --  execution  of  plan  may  not  always  achieve  goal 

Parameterize  goal  and  bind  parameter  a  priori  (wrong  value  may  make  goal 
impossible)  (§2.12) 

Find  a  necessary  condition  and  achieve  it  (§2.6) 

Order  choice  set  with  respect  to  goal  (§2.8.3) 


2.2.  The  Pigeon-hole  Principle 

The  pigeon-hole  principle  states  that 

A  thing  is  in  a  given  place  if  it  isn't  in  any  of  the  other  places  it  could  be. 

A  more  general  version  of  this  principle  is  represented  in  FOO: 

The  value  of  a  function  lies  in  a  given  set  if  the  rest  of  its  range  has  been  ruled  out. 

2.2.1.  Example:  Deciding  if  the  Queen  is  Out 

The  pigeon-hole  principle  is  used  in  DER1V4  to  devise  a  way  for  deciding  if  the  Queen  of  spades  is 
out  (ca,  held  by  an  opponent)  without  having  to  look  at  the  opponents’  cards: 
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4:2-6  —  [by  reformulation]  — > 

(EVAL  (IN  (LOC  QS)  (PROJECT  HAND  (OPPONENTS  ME)))) 

4:7  — -  [by  RULE169]  —  > 

(EVAL  (NOT  (IN  (LOC  QS) 

(DIFF  (RANGE  LOC) 

(PROJECT  HAND  (OPPONENTS  ME)))))) 

4:8-55  —  [by  analysis]  — > 

(EVAL  (NOT  (OR  [IN-POT  QS]  [AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  QS]))) 

None  of  these  steps  depends  on  any  property  specific  to  the  Queen  of  spades;  thus  replacing  every 
instance  of  the  symbol  QS  in  the  derivation  with,  say,  a  variable  CARD1,  would  produce  a  solution  of 
the  more  general  problem  (EVAL  (OUT  CARD1 ) ).  An  ideal  operationalizer  would  make  this 
observation  automatically  (§8.1.7).  A  similar  technique  was  used  in  STRIPS  to  generalize  a  plan 
constructed  to  solve  a  specific  problem  by  replacing  problem  constants  with  variables  wherever 
possible  [Hikes  71], 

The  fact  that  the  same  sequence  of  transformation  rules  would  work  for  the  more  general  problem 
justifies  using  the  same  solution  in  other  cases  requiring  the  ability  to  decide  whether  a  card  is  out, 
without  repeating  the  derivation  for  the  more  general  case.  For  example,  DERIV2  derives  a 
necessary  condition  for  whether  an  opponent  Pi  could  possibly  play  card  C2: 

(HAS  PI  C2 )  :  (=>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME))) 

This  condition  can  be  tested  given  a  way  to  determine  whether  card  C2  is  out.  In  DERIV10,  case 
analysis  based  on  the  pigeon-hole  principle  is  used  to  derive  an  evaluable  expression  for  the  number 
of  cards  out  in  a  given  suit;  this  number  is  used  to  estimate  the  probability  that  an  opponent  is  void  in 
the  suit 

The  pigeon-hole  principle  is  expressed  in 

RULE169:  (in  (f ...)  S)  ->  (not  (in  (f ...)  (difif  (range  0  S))) 

2,2.2.  Another  Example:  Prevent  an  Opponent  from  Getting  the  Lead 

The  pigeon-hole  principle  is  not  limited  to  finding  ways  to  compute  the  OUT  predicate.  For 
instance,  it  could  be  used  to  account  for  the  step 
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(NOT  (*  (LEAOER)  (QSO) ) ) 

3:91  ---  [by  RULE353]  ---> 

(-  (LEAOER)  ME) 

This  step  transforms  the  problem  of  preventing  the  player  who  has  the  Queen  of  spades  from 
getting  the  lead  into  the  problem  of  getting  the  lead  oneself.  In  DERIV3,  this  transformation  was 
accounted  for  by  the  somewhat  ad  hoc  rule 

RULE353:  (not  ( =  e  p))  ->  ( =  e  ME)  assuming  p  *  ME 

To  prevent  an  opponent  from  taking  on  some  role  (i.e.,  unsharable  position),  do  so  yourself. 

The  same  transformation  could  be  accounted  for  instead  by  the  sequence 
(NOT  (=■  (LEADER)  (QSO))) 

—  [by  reformulation]  — > 

(NOT  (IN  (LEAOER)  (SET  (QSO)))) 

—  [by  RULE169,  eliminating  double  negation]  — > 

(IN  (LEAOER)  (OIFF  (RANGE  (LEADER))  (SET  (QSO)))) 

-  [by  analysis]  - > 

(IN  (LEAOER)  (OPPONENTS  (QSO))) 

—  [by  finding  known  element  of  set]  — > 

(*  (LEADER)  ME) 

Here,  RULE169  captures  a  game  property  analogous  to  the  physical  law 
Two  objects  can't  occupy  the  same  space  at  the  same  lime. 


Specifically,  two  players  can’t  be  the  leader  of  the  same  trick. 


2.2.3.  Pigeon-Hole  Principle:  Summary 

Applying  the  pigeon-hole  principle  to  a  problem  involves  the  following  steps: 

1.  Reformulate  the  problem  in  terms  of  set  membership. 

2.  Transform  (in  (f  c)  S)  into  (not  (in  (f  c)  S'))  by  RULE169.  where  S'  is  the  complement  of  S  with 
respect  to  the  range  of  f. 

3.  Simplify  the  resulting  expression  to  make  it  evaluable. 


RULE169  itself  docs  very  little  of  the  work;  it  just  expresses  the  general  idea.  This  is  typical  of 
rules  that  express  ideas  about  how  to  operationalize.  A  possible  problem-solving  strategy  (§8.1.1)  for 
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an  operationalizer  would  use  such  rules  as  islands  (subgoal  generators)  in  the  operationalization 
search  space: 

Try  to  map  an  operationalization  problem  onto  known  operationalization  methods. 

Such  a  strategy  would  need  to  be  refined  so  as  to  consider  only  those  methods  appropriate  for  a 
particular  problem.  For  example,  there  is  no  point  in  applying  the  pigeon-hole  principle  to  an 
expression  that  is  already  evaluable. 


2.3.  The  Disjoint  Subsets  Method 

There  is  a  general  formula  for  the  probability  that  two  randomly-chosen  subsets  S,  S’  of  a  set  U  are 
disjoint: 

(Pr-disjoint  S  S’  U)  =  (#Choosc  |U-S’|  |S|)  /  (^Choose  |U|  |S|) 
where  (# Choose  n  k)  =  n!  /  kl(n-k)! 

This  formula  provides  the  basis  for  the  following  operationalization  strategy: 

Reformulate  a  predicate  as  an  assertion  that  two  subsets  of  a  common  superset  are  disjoint,  and 
evaluate  this  assertion  probabilistically  by  assuming  that  one  of  the  subsets  is  chosen  at  random, 
independently  of  the  other. 

This  strategy  may  be  useful  if  the  subsets  are  unevaluable  but  their  sizes  are  known. 

2.3.1.  Example:  Decide  If  an  Opponent  is  Void 

The  disjoint-subsets  method  is  used  in  DF.R1V9  to  estimate  the  probability  that  an  opponent  P0  is 
void  in  suit  SO.  Its  application  follows  the  scenario  outlined  in  the  Introduction  (§1.6): 

1.  Refonnulate  the  problem.  (§2.3.1.1) 

2.  Recognize  the  method’s  applicability.  (§2.3. 1.2) 

3.  Map  the  problem  onto  the  method.  (§2.3.1.3) 

4.  Fill  m  additional  information.  (§2.3. 1.4) 

5.  Refine  the  solution.  (§2.3.1.5) 

6.  Apply  the  result  (§2.3.1.6) 
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13.1.1  Reformulate  the  Problem 


The  first  step  of  the  derivation  reformulates  the  problem  as  a  predicate  on  an  unknown  set: 
(VOIO  PO  SO) 

9:1  ---  [ELABORATE  by  RULE124]  — > 

(NOT  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (iN-SUIT  Cl  SO))) 


These!  (CARD- IN-HAND  PO)  is  generally  unknown  to  player  ME,  since  the  rules  of  Hearts  prohibit 
direct  observation  of  opponents’  hands. 


2.3. 1.2  Recognize  the  Method’s  Applicability 


The  second  step  recognizes  that  the  disjoint  subsets  method  is  relevant,  and  reformulates  the 

expression  in  terms  of  disjoint  sets: 

(EXISTS  Cl  (CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO)) 

9:2-20  ---  [by  RULE189,  analysis]  — > 

(NOT  (OISJOINT  (CARDS- IN-HAND  PO)  (CARDS- IN-SUIT  SO))) 


The  idea  that  the  method  may  apply  to  a  predicate  on  an  unknown  set  is  expressed  in 
RULE189:  (P ...  S  ...)  ->  (h  (disjoint  S  S’))  for  suitable  h  and  S’  if  S  is  an  unknown  set 

HereP  =  EXISTS,  S  =  (CAROS-IN-HAND  PO),  h  =  NOT,  and  S’  =  (CARDS-IN-SUIT  SO).  As 
implemented,  RULE189  docs  not  actually  check  whether  S  is  unknown,  since  FOO  lacks  a  way  to 
predict  whether  an  expression  will  be  evaluable  at  runtime  (§8.1.1). 

2.3. 1.3  Map  the  Problem  to  the  Method 


The  problem  can  now  be  reformulated  to  match  the  problem  statement  for  die  method: 

(DISJOINT  (CARDS-IN-HAND  PO)  (CARDS-IN-SUIT  SO)) 

9:21  ---  [by  RULE198]  ---> 

(PR-DISOOINT 

(CARDS-IN-HAND  PO) 

(CARDS-IN-SUIT  SO) 

(COMMON-SUPERSET  (CARDS-IN-HAND  PO)  (CARDS-IN-SUIT  SO))) 


This  step  is  accounted  for  by 

RULE198:  (disjoint  S  S’)  ->  (Pr-disjoint  S  S’  (common-superset  S  S’))  if  S  is  unknown, 
assuming  S  is  randomly  chosen  independent  of  S’  or  vice  versa. 


No  attempt  was  made  to  verify  the  randomness  assumption  by  examining  the  rules  of  Hearts.  In 
fact,  this  assumption  is  false  if  play  has  begun.  Nonetheless,  as  with  any  method  based  on  a 
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simplifying  assumption,  the  disjoint  subsets  method  can  be  useful  if  the  assumption  is  a  reasonable 
approximation  of  reality.  The  more  accurate  the  assumption,  the  better  the  result  produced  by  the 
method. 

13.1.4  Fill  in  Additional  Information 

The  original  problem  didn't  explicitly  mention  a  common  superset,  so  one  must  be  found: 

(COMMON-SUPERSET  (CARDS- IN-HAND  PO)  (CARDS- IN-SUIT  SO))) 

9:23-25  -  [by  intersection  search]  - > 

(CARDS) 

13.1.5  Refine  the  Solution 

The  probability  that  player  PO  is  void  in  suit  SO  can  be  estimated  by  evaluating 
(PR-DISJOINT  (CARDS- IN-HAND  PO)  (CARDS- IN-SUIT  SO)  (CARDS)) 

=  (^Choose  39  (0CARDS- IN-HAND  PO))  /  (#ChOOse  52  (#CARDS- IN-HAND  PO)) 

However,  this  estimate  takes  too  little  information  into  account  to  be  of  much  use:  it  varies 
according  to  the  number  of  cards  left  in  PQ’s  hand  but  fails  to  discriminate  between  different  suits. 
This  solution  can  be  improved  by  finding  some  property  shared  by  (CARDS- IN-HAND  PO)  and 
considering  only  those  cards  that  have  it.  This  idea  is  expressed  more  precisely  in 

RULE200:  (Pr-disjoint  S  S’  U)  ->  (Pr-disjoint  S  (filter  S’  C)  (filter  U  C)), 
where  C  is  a  unary  predicate  satisfied  by  all  of  S,  Le„  such  that  S  =  (filter  S  C) 

RULE200  searches  the  knowledge  base  for  a  suitable  predicate  C  and  finds  the  predicate  OUT, 

originally  used  in  the  advice  “if  the  Queen  is  out,  flush  it’’: 

(PR-DISJOINT  (CARDS-IN-HAND  PO)  ( CARDS- IN-SUIT  SO)  (CARDS)) 

9:27-39  ---  [REFINE  by  RULE200  (C  =  OUT),  analysis]  — > 

(PR-DISJOINT  (CARDS-IN-HAND  PO)  (CARDS-OUT-IN-SUIT  SO)  (CARDS-OUT)) 


RULE200'$  condition  reduces  to  a  restricting  assumption: 

(’  (CARDS-IN-HAND  PO)  (FILTER  (CAROS- IN-HAND  PO)  OUT)) 

9:28-36  —  [by  analysis]  — > 

(IN  PO  (OPPONENTS  ME)) 

That  is,  all  members  of  (CARDS- IN-HANO  PO)  arc  OUT  provided  PO  is  an  opponent  of  ME  --  a 
restriction  not  made  explicitly  in  the  original  problem  statement  ( EVAL  (VOID  PO  SO) )  (§5.9.3.2.2). 
The  domain  knowledge  used  in  this  analysis  includes  such  information  as  the  definition  of  S  = 
(CARDS- IN-HANO  PO),  although  the  only  information  about  S  required  by  the  probability  formula  is 
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the  size  of  S.  This  illustrates  how  the  information  required  to  refine  a  method  may  go  beyond  the 
information  required  to  apply  it. 

2.3.1.6  Apply  the  Method 

The  method  is  applied  by  plugging  in  the  formula: 

(PR-OISJOINT 

(CAROS -IN -HAND  PO) 

( CARDS -OUT -IN-SUIT  SO) 

(CARDS-OUT)) 

9:40-43  —  [apply  by  RULE124,  analysis]  — > 

( PR -DISJOINT -FORMULA 
(#CARDS-IN-HAND  PO) 

(#CARDS -OUT -IN-SUIT  SO) 

(jCCARDS-OUT)) 

This  expression  estimates  the  probability  that  player  PO  is  void  in  suit  SO,  given  the  number  of 
cards  held  by  player  PO,  the  number  of  cards  out  in  suit  SO.  and  the  total  number  of  cards  out.  These 
quantities  can  be  computed  by  remembering  which  cards  have  been  played  (§2.4).  Unlike  the  initial 
solution,  this  refined  solution  takes  into  account  the  cards  in  suit  SO  held  by  player  ME  or  previously 
played.  An  alternative  to  evaluating  the  expression  directly  to  produce  a  numerical  probability 
estimate  is  to  operate  on  it  by  other  methods  (§2.8). 

2.3.2.  Another  Example:  Avoid  Taking  Points 

Since  the  disjoint  subsets  method  is  potentially  applicable  to  predicates  on  unknown  sets,  it’s 
interesting  to  apply  it  to  the  “avoid  taking  points"  example  in  the  case  where  player  ME  must  follow 
suit: 

(AVOID-TAKING-POINTS  (TRICK)) 

---  [by  analysis,  assuming  (IN-SUIT-LED  (CARD-OF  ME))]  ---> 

(EXISTS  XI  (CARDS-PLAYED-BY-OPPONENTS) 

(ANO  [IN-SUIT-LED  XI]  [LOWER  (CARD-OF  ME)  XI])) 

—  [map  to  method  by  RULE189,  analysis]  — > 

(NOT  (DISJOINT  (CAROS-PLAYED-BY-OPPONENTS) 

(CARDS- IN-SUIT -LED- ABOVE  (CARD-OF  ME)))) 

—  [fill  in  argument  by  RULE198,  analysis]  — > 
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(-  1  (PR-DISJOINT 

(CAROS -PLAYED- BY-OPPONENTS) 

( CARDS- IN -SUIT -LEO- ABOVE  (CARO-OF  ME)) 

(CARDS))) 

—  [REFINE  by  RULE200  (C  *  IN-SUIT-LED),  analysis]  — > 

(-  1  (PR-DISJOINT 

(CARDS- IN-SUIT -LED- PLAYED-BY -OPPONENTS) 

(CARDS- IN-SUIT-LED-ABOVE  (CARD-0 F  ME)) 

(CARDS- IN-SUIT -LED) ) ) 

(CAROS-IN-SUIT-LED-PLAYED-BY-OPPONENTS)  --  ail  of  which  were  legal 
—  [by  analysis  of  LEGAL]  — > 

( CARDS- PL  AYED-8Y -NON -VO  ID -OPPONENTS)  --  all  of  which  wen-  out 

—  [REFINE  by  RULE200  (C  =  OUT),  analysis]  — > 

(-  1  (PR-DISJOINT 

( CAROS- PLAYED-8Y- NON -VO  ID -OPPONENTS) 

(CARDS-OUT- IN-SUIT-LEO-ABOVE  ( CARD-OF  ME)) 

(CARDS-OUT- IN-SUIT -LEO) ) ) 

—  [apply  by  RULE124.  analysis]  — > 

(-  1  (PR-OISJOINT-FORMULA 

(#NON -VO ID- OP PON ENTS) 

(#CARDS-OUT- IN-SUIT -LED- ABOVE  (CARD-OF  ME)) 
(#CAROS-OUT-IN-SUIT-LED))) 


This  expression  estimates  the  probability  that  one  of  player  ME’s  opponents  will  play  a  higher  card 
(in  the  suit  led)  than  (CARD-OF  ME),  assuming  that  they  choose  randomly  from  their  legal  cards ,  or 
more  precisely  that  the  cards  played  in  the  suit  led  are  chosen  randomly  from  those  that  arc  oul  This 
unrealistic  model  is  a  built-in  assumption  of  the  method.  A  more  realistic  approach  is  to  estimate  the 
probability  that  all  of  player  ME's  non-void  opponents  can  choose  cards  lower  than  (CARO-OF  ME), 
rather  than  the  probability  that  they  will  randomly  happen  to  do  so.  The  revised  problem  consists  of 
finding  a  way  to  evaluate  the  assertion 

(FORALL  PI  (NON-VOID-OPPONENTS  ME) 

(CAN-UNDERPLAY  PI  (CARD-OF  ME))) 


Applying  the  disjoint  subsets  method  to  the  quantified  term  might  produce  something  like  this: 
(CAN-UNDERPLAY  PI  (CARD-OF  ME)) 

—  [by  analysis]  — > 

(EXISTS  XI  (CARDS- IN-SUIT -LED- IN -HAND  PI) 

(LOWER  XI  (CARD-OF  ME))) 


—  [map  to  method  by  RULE189,  analysis]  — > 
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(NOT  (OISJOINT  (CAROS- IN-SUIT-LED-IN-HANO  PI) 

(CARDS-IN-SUIT-LED-BELOW  (CARO-OF  ME)))) 

—  [fill  in  argument  by  RULE198,  analysis]  — > 

(-  1  (PR-OISJOINT 

(CARDS- IN-SUIT -LED- IN-HAND  PI) 

(CARDS-IN-SUIT-LED-BELOW  (CARD-OF  ME)) 

(CARDS- IN-SUIT -LED) ) ) 

-  [REFINE  by  RULE200  (C  *  OUT),  analysis]  ---> 

(-  1  (PR-DISJOINT 

( CARDS- IN-SUIT-LED- IN-HAND  Pt) 

(CARDS-OUT-IN-SUIT-LED-BELOW  (CARD-OF  ME)) 
(CAROS-OUT-IN-SUIT-LED) ) ) 

Here  some  difficulties  arise.  First.  (#CARDS-IN-SUIT-LED-IN-HAND  PI)  is  generally  unknown. 
Second,  the  obvious  way  to  estimate  the  probability  that  all  of  plyaer  ME’s  non-void  opponents  can 
underplay  (CARD-OF  ME)  is  to  assume 

(Pr  [FORALL  PI  (NON-VOID-OPPONENTS  ME) 

(CAN-UNDERPLAY  PI  (CARD-OF  ME))]) 

=  (PRODUCT  PI  (NON-VOID-OPPONENTS  ME) 

(PR-CAN-IJNDERPLAY  PI  (CARD-OF  ME))) 

However,  this  estimate  is  imperfect  because  the  probabilities  that  different  opponents  Pi  can 
underplay  (CARD-OF  ME)  are  not  independent  For  instance,  if  only  one  card  lower  than 
(CARD-OF  ME)  is  still  out,  two  different  opponents  can’t  both  play  it.  Third, 
(#N0N-V0 ID-OPPONENTS  ME)  is  not  directly  evaluable,  although  its  expected  value  can  be  estimated 
as 

(SUM  PI  (OPPONENTS  ME) 

(PR-NON-VOID-IN-SUIT-LED  PI)) 

Actually,  the  relevant  quantity  is  the  probability  that  the  cards  lower  than  (CARD-OF  ME)  are 
distributed  so  that  every  non-void  opponent  has  at  least  one.  A  necessary  condition  for  such  a 
distribution  is 

(>=  (#C ARDS-OUT- IN-SUIT -BELOW  (CARD-OF  ME))  (0NON-VOID-OPPONENTS) ) 

That  is,  there  must  be  enough  of  them  to  go  around.  However,  it  is  not  obvious  how  to  derive  this 
condition  mechanically  from  the  original  problem  (AVOID-TAKING-POINTS  (TRICK)).  This  may 
be  a  limitation  of  the  method  rather  than  of  the  apparatus  for  applying  it.  A  more  natural 
combinatorial  model  for  this  problem  than  the  disjoint  subsets  model  is  the  number  of  ways  to  put  n 
balls  in  k  slots  without  leaving  any  of  them  empty. 
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23.3.  Disjoint  Subsets  Method:  Summary 

The  disjoint  subsets  method  provides  a  way  to  estimate  the  probability  that  a  set  S  satisfies  an 
assertion  (P  ...  S  ...).  To  apply  the  method,  it  is  necessary  to  reformulate  (P  ...  S  ...)  as  a  function  of 
whether  S  is  disjoint  from  some  other  set  S’,  where  S  and  S’  are  assumed  to  be  chosen  independently 
at  random  from  some  common  universe  U.  The  estimate  provided  by  the  method  depends  only  on 
the  sizes  of  the  sets  S,  S’,  and  U,  and  is  therefore  useful  in  evaluating  assertions  about  sets  of  known 
size  and  unknown  membership.  The  estimate  can  be  refined  if  all  members  of  S  are  known  to  satisfy 
some  condition  C,  and  the  sets  (filter  S’  C)  and  (filter  U  C)  have  known  size. 

2.4.  Historical  and  Causal  Reasoning 

Sometimes  evaluating  an  expression  involves  remembering  previous  events  or  conditions.  Certain 
operationalization  problems  can  be  solved  by  deciding  ahead  of  time  to  remember  such  information. 
For  instance,  it’s  a  good  idea  to  keep  track  of  whether  the  Queen  of  spades  has  been  played,  who’s 
void  in  what  suit,  and  how  many  cards  are  out  in  each  suit.  This  section  describes  rules  for  deciding 
what  to  remember;  the  solutions  they  produce  contain  “historical  references”  [Balzer  79]  - 
expressions  defined  in  terms  of  past  events.  Implementing  such  solutions  efficiently  with  appropriate 
demons  and  data  structures  is  a  separate  problem  that  has  been  addressed  by  others  [Barstow 
77]  [Low  78]. 

Another  type  of  reasoning  used  in  operationalization  involves  finding  an  action  with  a  specified 
effect,  such  as  causing  a  given  predicate  to  become  true  or  false.  This  is  important  both  for 
constmcting  plans  to  achieve  a  desired  effect  and  for  reasoning  from  observed  events  to  their 
consequences  and  vice  versa. 

Historical  and  causal  reasoning  are  closely  related,  and  it  is  useful  to  discuss  them  together.  The 
examples  in  this  section  show  among  other  things  how  one  type  of  reasoning  depends  on  the  other. 

2.4.1.  Deciding  if  the  Queen  is  Out 

Historical  reasoning  is  illustrated  in  the  previously  described  problem  of  deciding  whether  the 
Queen  of  spades  is  out  (§2.2.1).  Applying  the  pigeon-hole  principle  to  that  problem  splits  it  into 
several  subproblems,  one  of  which  is  deciding  whether  the  Queen  is  in  an  opponent’s  pile; 


§2.4.1.  Deciding  if  the  Queen  is  Out 
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(IN  (LOC  QS)  (PILES  (PLAYERS))) 

4:44-46  —  [by  analysis]  — > 

(EXISTS  P3  (PLAYERS)  (AT  QS  (PILE  P3))) 


Common  sense  says  that  if  the  Queen  is  in  player  P3‘s  pile  and  it  wasn’t  there  at  the  beginning  ot 

the  round,  it  had  to  get  there  somehow: 

(AT  QS  (PILE  P3 ) ) 

4:47  —  Ley  RULE356]  —  > 

(OR  [WAS-DURING  (CURRENT  ROUND-IN-PROGRESS) 

(CAUSE  (AT  QS  (PILE  P3)))] 

[BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (AT  QS  (PILE  P3)}]) 


This  reasoning  is  expressed  more  generally  by 

RULE356:  P  ->  (or  [was-during  (current  A)  (cause  P)]  [before  (current  A)  P]), 
where  A  is  an  event  type 

The  fact  that  players’  piles  are  empty  at  the  beginning  of  the  round  could  in  principle  be  inferred 
from  the  description  of  the  game: 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (AT  QS  (PILE  P3 ) ) ) 

4:48  —  [EVAL  by  RULE357]  — -> 

NIL 


However,  here  this  inference  is  simulated  by  a  Hearts-specific  “fact  rule”  (§1.3.3): 

RULE357:  (before  (current  round-in-progress)  (at  c  (pile  p)))  ->  nil 
for  any  card  c  and  player  p 

Causing  something  to  be  somewhere  means  moving  it  there: 

(CAUSE  (AT  QS  (PILE  P3))) 

4:51  ---  [RECOGNIZE  by  RULE358]  — -> 

(MOVE  QS  LOCI  (PILE  P3)) 


This  general  fact  is  expressed  by 

RULE358:  (cause  (at  obj  loc))  ->  (move  obj  loc’  loc) 
where  loc'  is  the  previous  location  of  die  object  obj 


The  game  description  mentions  only  one  action  that  moves  a  card  to  a  pile: 

(MOVE  QS  LOCI  (PILE  P3)) 

4:52  ---  [RECOGNIZE  by  RULE123]  — -> 

(TAKE  P3  QS) 


The  resulting  expression  can  be  rewritten  in  terms  of  a  recognized  concept: 
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(EXISTS  P3  (PLAYERS) 

(WAS-DURING  (CURRENT  ROUNO-IN-PROGRESS)  (TAKE  P3  QS))) 
4:53-54  —  [RECOGNIZE  by  RULE123]  — > 

(TAKEN  QS) 


It  would  be  straightforward  to  implement  this  expression  as  a  boolean  value  initialized  to  false  at 
the  beginning  of  the  round  and  set  to  true  by  a  demon  when  the  Queen  was  taken.  (However,  this  is 
beyond  the  scope  of  FOO,  which  doesn’t  know  about  data  structures  (§8.1.5)  and  provides  no  way  to 
specify  the  time  at  which  a  given  expression  should  be  evaluated  (§8.1.1).)  This  solution  will  work 
provided  player  ME  observes  the  Queen  being  taken;  if  the  Queen  was  the  hole  card  (taken  by  the 
winner  of  the  first  trick  and  seen  only  by  him),  player  ME  will  think  it’s  still  out,  just  as  a  human 
player  might. 


2.4.2.  Remembering  that  an  Opponent  is  Void 


A  player  who  happens  to  conclude  that  an  opponent  is  void  (e.g.,  by  noticing  when  he  or  she 
breaks  suit)  can  remember  this  inference  and  use  it  later,  since  anyone  who  becomes  void  stays  void 
for  the  rest  of  the  round  (although  not  for  the  rest  of  the  game!).  The  idea  of  deciding  whether  a 
player  is  void  by  remembering  if  he  or  she  was  void  earlier  in  the  round  is  derived  in  DERIV12: 

(VOID  PO  SO) 

12:1-13  ---  [by  RULE234 ,  analysis]  — > 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS)  (VOID  PO  SO)) 


This  solution  is  found  by  looking  for  an  event  during  which  (VOID  PO  SO)  can’t  become  false: 
RULE234:  P  ->  (was-during  (current  A)  P) 

if  P  is  irreversible  during  events  of  type  A,  ie.,  (not  (during  (A)  (undo  P))) 

Most  of  the  derivation  consists  of  verifying  the  rule  condition  for  A  =  ROUND- IN-PROGRESS: 

(NOT  (DURING  ( ROUND- IN-PROGRESS )  (UNDO  (VOID  PO  SO)))) 

12:2-12  —  [by  analysis]  — > 

T 


The  proof  of  this  condition  begins  by  reformulating  it  in  terms  of  causing  a  change  in  location: 

(UNDO  (VOID  PO  SO)) 

12:2-8  —  [by  analysis]  — > 

(EXISTS  Cl  (CARDS) 

(AND  [CAUSE  (AT  Cl  (HAND  PO))]  [IN-SUIT  Cl  SO])) 


This  enables  the  application  of  the  previously  described  RULE358: 
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(CAUSE  (AT  Cl  (HANO  PO))) 

12:9  ---  [RECOGNIZE  by  RULE358]  ---> 
(MOVE  Cl  LOCI  (HANO  PO}) 


Moving  a  card  to  a  player’s  hand  is  recognized  as  a  special  case  of  MOVE: 

(MOVE  Cl  LOCI  (HANO  PO)) 

12:10  —  [RECOGNIZE  by  RULE123]  — > 

(GET-CARO  PO  Cl  LOCI) 


An  intersection  search  (§5.6)  through  the  knowledge  base  establishes  that  no  card  is  moved  to  any 
player’s  hand  while  a  round  is  in  progress  (Le„  after  the  cards  have  been  dealt  out  and  any  passing  has 
taken  place): 

(OURING  (ROUNO- IN -PROGRESS) 

(EXISTS  Cl  (CAROS) 

(AND  [GET-CARD  PO  Cl  LOCI]  [IN-SUIT  Cl  SO]))) 

12:11  ---  [COMPUTE  by  RULE57]  — > 

NIL 


This  completes  the  proof. 


2.4.3.  Keeping  Count  of  the  Cards 

The  expression  derived  earlier  for  estimating  the  probability  that  an  opponent  is  void  in  suit  SO 
depends  on  the  number  of  cards  in  SO  still  out,  Le.,  held  by  player  ME’s  opponents.  Without  looking 
at  their  hands,  how  can  this  number  be  computed?  The  solution  derived  in  DER1V10  is  the  formula 
13  -  M  -  P,  where  M  is  the  number  of  cards  in  SO  held  by  ME  when  the  round  began,  and  P  is  the 
number  of  cards  in  SO  played  so  far  by  opponents  of  ME.  This  is  done  as  follows. 


First  the  expression  is  reformulated  to  fit 

RULE370:  (#  (set-of  x  S  Px))  -> 

(-  ( #  (set-of  x  S  (before  (current  A)  Px))) 

(#  (set-of  x  S  (was-during  (current  A)  (undo  Px)))))  ' 
if  P  is  unachievable  during  events  of  type  A,  Le..  (not  (during  A  (cause  P))) 


This  rule  counts  the  elements  of  a  set  that  satisfy  some  property: 

(0CARDS-OUT-IN-SUIT  SO) 

10:1-3  —  [ELABORATE  by  RULE124]  ---> 

(#  (SET-Of  XI  (CAROS-IN-SUIT  SO)  (OUT  XI))) 


RULE370  exploits  the  fact  that  the  number  of  cards  out  in  suit  SO  now  is  the  number  that  were  out 
when  the  round  started,  less  those  that  have  been  played  since  then: 
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(#  (SET-OF  XI  (CARDS-IN-SUIT  SO)  (OUT  XI))) 

10:4-12  ---  [by  RULE370]  — -> 

(-  {*  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUNO-IN-PROGRESS)  (OUT  XI)))) 
(#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS) 

(UNDO  (OUT  XI)))))) 


The  validity  of  this  reasoning  depends  on  there  being  no  way  during  the  round  for  a  card  to 

become  out,  Le.,  enter  an  opponent’s  hand.  Much  of  the  derivation  consists  of  verifying  this 

condition,  which  comes  from  taking  A  =  ROUND-IN-PRQGRESS  in  RULE370: 

(NOT  (DURING  (ROUNO-IN-PROGRESS)  (CAUSE  (OUT  XI)))) 

10:5-11  —  [by  analysis]  — > 

T 


Verification  of  the  condition  begins  by  reformulating  it  in  terms  of  a  change  in  location: 

(CAUSE  (OUT  XI)) 

10:5-7  —  [by  analysis]  — > 

(EXISTS  XI  (CARDS) 

(CAUSE  (AT  XI  (HAND  P0)))) 


This  change  of  location  is  recognized  as  a  moving  a  card  to  player  PO’s  hand: 

(CAUSE  (AT  XI  (HAND  PI))) 

10:8  ---  [RECOGNIZE  by  RULE358]  ---> 

(MOVE  XI  LOCI  (HAND  PI)) 

10:9  ---  [RECOGNIZE  by  RULE1Z3]  — > 

(GET-CARD  P0  XI  LOCI) 


A  knowledge  base  intersection  search  establishes  that  no  card  can  be  moved  to  any  player’s  hand 

while  a  round  is  in  progress: 

(DURING  (ROUND-IN-PROGRESS) 

(EXISTS  PI  (OPPONENTS  ME) 

(GET-CARD  PI  XI  LOCI))) 

10:10  —  [COMPUTE  by  RULE57]  — -> 

NIL 


This  completes  the  verification  of  RULE370’s  condition.  The  next  part  of  the  derivation  simplifies 

the  first  term  of  the  formula 

(-  (#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUNO-IN-PROGRESS)  (OUT  XI)))) 

(#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS) 

(UNDO  (OUT  XI)))))) 


First  the  pigeon-hole  principle  is  applied,  followed  by  some  case  analysis: 
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(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (OUT  XI))  ' 

10:14-22  -  [by  analysis]  — > 

(NOT  (BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI))) 


The  number  of  cards  one  doesn  V  have  in  a  suit  is  13  minus  the  number  one  does  have: 

(4»  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(NOT  (BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI)))) 
10:23-24  ---  [by  analysis]  — > 

(-  13  (#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI))))) 


The  rest  of  the  derivation  reformulates  the  second  part  of  the  formula  in  terms  of  causing  a  change 
in  location: 

(H  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS) 

(UNDO  (OUT  XI)) 

10:25-28  —  [by  analysis]  — > 

(#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-OURING  (CURRENT  ROUND-IN-PROGRESS) 

(EXISTS  P3  (OPPONENTS  ME) 

(UNDO  (AT  XI  (HAND  P 3))))))) 


This  expression  is  recognized  in  terms  of  card-moving  by  applying  die  inverse  of  RULE358: 

RULE368:  (undo  (at  obj  loc))  ->  (move  obj  loc  toe’) 
where  loc’  is  the  new  location  of  the  object  obj 

(UNDO  (AT  XI  (HAND  P3))) 

10:29  ---  [RECOGNIZE  by  RULE368]  — > 

(MOVE  XI  (HAND  P3)  LOC2) 

10:30  ---  [RECOGNIZE  by  RULE123]  — > 

(PLAY  P3  XI) 


The  final  result  corresponds  to  the  formula  13  -  M  -  P,  or  (-  (- 13  M)  P)  in  prefix  notation: 

(-  (-  13  (if  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI))))) 
(#  (SET-OF  XI  (CARDS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS) 

(EXISTS  P3  (OPPONENTS  ME)  (PLAY  P3  XI)))))) 


2.4.4.  Reasoning  about  Actions  from  First  Principles 

The  above  derivations  use  RULE358  and  RULE368,  which  relate  motion  to  location.  Note  that 
RULF.368  is  also  used  in  DERIV8  to  help  construct  a  plan  for  getting  void  in  suit  SO  by  finding  an 
action  to  get  rid  of  a  card: 

(REM0VE-1-FR0M  (SET-OF  Cl  ( CARDS- IN-HAND  ME)  (IN-SUIT  Cl  SO))) 
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8:4  —  [REOUCE  by  RULE7]  — > 

(UNDO  (AND  [IN  Cl  (CARDS- LN-HANO  ME)]  [IN-SUIT  Cl  SO])) 

8:5-9  —  [by  analysis]  — > 

(AND  [UNDO  (AT  Cl  (HAND  ME))]  [IN-SUIT  Cl  SO]) 

8:10  —  [RECOGNIZE  by  RULE368]  ---> 

(AND  [MOVE  Cl  (HAND  ME)  LOCI]  [IN-SUIT  Cl  SO]) 

8:11-14  ---  [RECOGNIZE  by  RULE123,  analysis]  — -> 
(PLAY-SUIT  ME  SO) 


These  rules  serve  as  shortcuts;  it’s  actually  possible  to  derive  the  same  result  from  the  definition 

MOVE  =  (LAMBDA  (OBJ  ORIG  DEST) 

(AND  [=  (LOC  OBI)  ORIG]  [BECOME  (LOC  OBJ)  OEST])) 


This  is  illustrated  in  the  following  excerpt  from  DERIV3,  where  the  problem  is  to  find  an  action 

that  undoes  player  (QSO)’s  possession  of  card  C3.  The  approach  taken  is  to  try  to  instantiate  an 

action  concept  selected  from  the  knowledge  base  so  as  to  have  the  desired  effect; 

(UNDO  (HAS  (QSO)  C3)) 

3:46  ---  [by  RULE254]  ---> 

(SHOW  (=>  [PLAY  PI  C4]  [UNDO  (HAS  (QSO)  C3)])) 


Here  the  selected  concept  is  PLAY,  whose  arguments  PI  and  C4  arc  to  be  solved  for.  This  idea  is 
suggested  by 

RULK254:  (C  P) ->  (A  Vj ...  vn) 

if  ( A  ...  vn)  =  >  (C  P)  for  some  action  type  A  and  argument  values  Vj ...  vfl, 

where  C  is  a  modal  operator  (eg.,  “cause"  or  “undo”)  denoting  change  over  time 


As  implemented.  RULE254  lists  the  action  concepts  in  the  current  task  domain  and  asks  the  user 
to  select  one  to  use  as  A;  an  alternative  would  be  to  use  trial  and  error  to  find  one  that  works,  Le., 
satisfies  the  rule  condition  for  some  assignment  of  values  to  its  arguments. 


In  the  current  example,  the  process  of  solving  for  the  arguments  of  PLAY  begins  by  expanding  the 

definitions  of  has  and  AT: 

(SHOW  (*>  [PLAY  PI  C4] 

[UNDO  (HAS  (QSO)  C3)])) 

3:47-48  —  [ELABORATE  by  RULE124]  ---> 

(*  (LOC  C3)  (HAND  (QSO))) 


Applying  die  definition  of  UNDO  enables  the  recognition  of  MOVE: 
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(UNDO  (=  (LOC  C3)  ( HAND  (QSO) ) ) ) 

3:49  ---  [ELABORATE  by  RULE344]  — > 

(AMO  [=  (LOC  C3 )  (HAND  (QSO))]  [BECOME  (LOC  C3)  LOC3]) 
3:50  ---  [RECOGNIZE  by  RULE123]  ---> 

(MOVE  C3  (HAND  (QSO))  LOC3) 


The  action  PLAY  can  also  be  expressed  in  terms  of  MOVE: 

(PLAY  PI  C4) 

3:51  ---  [ELABORATE  by  RULE124]  — -> 

(MOVE  C4  (HAND  PI)  POT) 

The  two  descriptions  of  MOVE  events  are  matched,  and  their  corresponding  components  equated: 

(*>  [MOVE  C4  (HANO  PI)  POT]  [MOVE  C3  (HAND  (QSO))  LOC3]) 

3:52  —  [DISTRIBUTE  by  RULE43]  — -> 

(AND  [*  C4  C3]  [»  (HAND  PI)  (HAND  (QSO))]  [»  POT  L0C3]) 

The  makes  it  possible  to  solve  for  the  arguments  PI  and  C4  in  (PLAY  Pi  C4).  Plugging  in  the 

solved  values  yields  an  action  with  the  desired  effect  (UNDO  (HAS  (QSO)  C3))): 

3:53-61  —  [by  analysis]  — > 

(PLAY  (QSO)  C3) 

2.4.5.  Historical  and  Causal  Reasoning:  Summary 

Knowledge  about  actions  and  their  consequences  is  encoded  in  a  variety  of  rules  in  FOO.  It  is 
useful  to  try  to  impose  some  structure  on  this  collection. 

2.4.5. 1  A  Model  of  Historical  Reasoning 

The  three  examples  of  historical  reasoning  (§2.4.1)  (§2.4.2)  (§2.4.3)  used  three  different  rules. 
However,  all  three  arc  consequences  of  the  same  general  relationship  between  the  truth  of  a 
proposition  P  now  and  at  a  previous  time  t: 

P  is  true  now  iff 

P  became  true  more  recently  than  it  became  false 

or  P  was  true  at  lime  t  and  has  not  become  false  since  then. 

The  condition  “P  became  true  more  recently  than  it  became  false”  is  rather  messy  to  encode,  since 
it  involves  nested  quantification  over  time.  It  can  be  considerably  simplified  given  certain  restrictions 
on  the  possibility  of  P  changing.  Each  of  the  three  rules  follows  from  such  a  restriction: 

RULE234:  If  P  can’t  become  false  once  it's  true,  it’s  true  now  if  it  was  true  at  any  earlier  time. 
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RULE356:  If  P  can’t  become  false  once  it’s  true,  it’s  true  now  iffil  was  true  at  time  t  or  became 
true  anytime  since  then. 

RULE370:  If  P  can't  become  true  once  it’s  false,  it’s  true  now  iff  it  was  true  at  time  t  and  hasn’t 
become  false  since  then.  (RULE370  also  incorporates  some  knowledge  about  counting  that 
could  be  encoded  separately.) 

Thus  while  the  rules  differ,  they  are  accounted  for  by  the  same  simple  model. 

14.5.2  Finding  Actions  with  Specified  Effects 

FOO’s  rules  about  causality  appear  quite  general  with  respect  to  the  rather  simple  examples  to 
which  they  were  applied.  The  two  rules  for  relating  motion  and  location  (RULE358  and  RULE368) 
were  pleasingly  symmetric  and  used  more  than  once.  Intersection  search  through  the  space  of 
defined  action  concepts  was  adequate  in  several  instances  to  quickly  show  'hat  one  type  of  event 
couldn’t  occur  during  another.  This  technique  relied  on  two  properties  of  the  knowledge  base: 

The  closure  property  guarantees  that  the  known  concepts  include  all  types  of  actions  that  can 
(legally)  occur  in  the  task  environment.  For  instance,  since  the  description  of  the  first  part  of  a  trick 
mentions  only  that  each  player  plays  a  card,  FOO  can  safely  assume  that  no  poltergeist  is  secretly 
moving  cards  around  at  the  same  time. 

The  canonical  definition  property  guarantees  that 

1.  All  the  card-moving  actions  arc  ultimately  defined  in  terms  of  MOVE. 

2.  No  two  action  concepts  defined  directly  in  terms  of  MOVE  (GET-CARD.  PLAY,  TAKE)  can  describe 
the  same  event. 

This  guarantees  the  type  incompatibility  of  any  two  concepts  with  no  sub-event  concepts  in 
common  above  the  level  of  MOVE  (§5.6).  For  instance,  since  undoing  a  void  requires  getting  a  card, 
and  GET-CARD  is  not  a  sub-event  of  ROUND-IN-PROGRESS,  FOO  can  conclude  that  a  player  who 
becomes  void  stays  void  for  the  rest  of  the  round. 

14.5.3  Significance 

This  section  has  presented  some  elementary  but  general  techniques  for  reasoning  about  task 
domains  involving  change  over  time.  Historical  reasoning  analyzes  the  current  value  of  an  expression 
in  terms  of  its  value  at  an  earlier  time  and  events  that  have  occurred  since  that  time.  This  type  of 
reasoning  is  important  in  task  domains  where  key  features  of  the  environment  cannot  be  observed 
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directly  but  must  be  inferred  from  observed  behavior.  Causal  reasoning  analyzes  a  change  in  the 
value  of  an  expression  in  terms  of  the  actions  that  could  cause  it.  This  type  of  reasoning  is  important 
in  planning,  where  the  object  is  to  find  an  executable  action  that  produces  a  desired  effect.  As  AI 
addresses  increasingly  complex  task  domains,  the  utility  of  general  mechanical  methods  for  reasoning 
about  them  will  increase  accordingly. 


2.5.  Depleting  a  Set 

One  of  the  operationalization  methods  in  FOO  is 

To  achieve  a  goal  of  the  form  " make  set  S  empty, "  remove  one  element  at  a  time  from  S  until  the 
goal  is  accomplished. 

This  simple  strategy  underlies  two  plans  derived  using  FOO:  to  get  void  in  a  given  suit  keep 
playing  cards  from  that  suit;  to  flush  the  Queen,  keep  leading  spades.  In  both  cases,  most  of  the  work 
consists  of  reformulating  the  goal  in  terms  of  emptying  a  set  and  then  finding  an  executable  action 
that  removes  an  element  from  it 


2.5.1.  Getting  Void 


A  plan  for  getting  void  in  a  given  suit  SO  is  derived  in  DERIV8.  The  derivation  begins  by 

reformulating  the  goal  in  terms  of  emptying  a  set: 

(ACHIEVE  (VOID  ME  SO)) 

8:1-2  —  [by  analysis]  — > 

(ACHIEVE  (EMPTY  (SET-OF  Cl  (CAROS- IN-HAND  ME) 

(IN-SUIT  Cl  SO)))) 


This  enables  application  of  the  general  strategy  for  depleting  a  set: 

8:3  ---  [REDUCE  by  RULE6]  — > 

(UNTIL  (VOID  ME  SO) 

(ACHIEVE  ( REM0VE-1-FR0M  (SET-OF  Cl  (CARDS- IN-HAND  ME) 

(IN-SUIT  Cl  SO))))) 


The  set  depletion  strategy  is  expressed  by 

RULE6:  (achieve  (empty  S))  ->  (until  P  (achieve  ( remove- 1- from  S))), 
where  P  is  the  original  goal 

Now  the  real  work  begins:  figuring  out  how  to  remove  an  element  from  the  set  Removing  an 
clement  from  {x  in  S  |  Px}  means  either  removing  an  clement  of  S  or  undoing  Px  for  some  x  in  S: 
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( REMOVE- 1-FROM  (SET-OF  Cl  (CAROS- IN-HAND  ME)  (IN-SUIT  Cl  SO))) 

8:4  ---  [by  C7T  — > 

(UNDO  (AND  [IN  Cl  (e^RDS-IN-HAND  ME)]  [IN-SUIT  Cl  SO])) 

This  general  idea  is  expressed  by 

RULE7:  (remove- 1- from  (set-of  x  S  Px))  ->  (undo  (and  [in  x  S]  [Px]))  for  some  x  in  S 

Undoing  a  conjunction  means  undoing  one  of  its  conjuncts  when  the  others  were  all  true: 

8:5  —  [REDUCE  by  RULE35]  — -> 

(AND  [UNDO  (IN  Cl  (CARDS-IN-HAND  ME))]  [IN-SUIT  Cl  SO]) 

This  reduction  is  suggested  by 

RULE35:  (C  (and  ...  Pn))  ->  (and  [C  PJ  ...  PK  Pj+ , ...  Pn)  for  some  P, 
where  C  is  a  modal  operator  ( e.g .,  "cause”  or  "undo”)  denoting  change 

This  rule  says  nothing  about  which  P(  to  choose.  One  obvious  criterion  is  not  to  choose  a  P(  known 
to  be  immutable.  For  example.  (IN-SUIT  Cl  SO)  is  permanently  true  or  false  for  a  given  card  Cl 
and  suit  SO,  since  a  card  can’t  change  its  suit.  (In  contrast,  consider  chess,  where  a  pawn  can  become 
another  piece.)  This  property  could  be  derived  from  the  domain  knowledge  base  using  the 
techniques  described  earlier  (§2.4),  or  acquired  simply  by  interrogating  a  domain  expert.  As 
implemented,  RULE35  asks  the  user  to  select  P(.  In  the  current  example,  P(  was  chosen  to  be 
(IN  Cl  (CARDS-IN-HAND  ME)).  Alternatively,  this  choice  could  be  discovered  by  trial  and  error, 
since  no  action  in  the  Hearts  domain  can  undo  (IN-SUIT  Cl  SO). 

Next  (IN  Cl  (CARDS-IN-HAND  ME ))  is  elaborated  as  a  conjunction,  and  one  of  its  conjuncts  is 

chosen  to  be  undone,  once  again  using  RUI.E35: 

(UNOO  (IN  Cl  (CARDS-IN-HAND  ME))) 

8:6-7 - [by  analysis]  — > 

(UNDO  (AND  [IN  Cl  (CARDS)]  [HAS  ME  Cl])) 

8:8  —  [REDUCE  by  RULE35]  — > 

(AND  [IN  Cl  (CARDS)]  [UNDO  (HAS  ME  Cl)]} 

Here  die  alternative  would  be  to  make  Cl  stop  being  a  card.  Actions  with  this  effect  arc  physically 
possible  (e.g..  burning),  but  arc  not  part  of  the  domain  description. 

The  action  of  undoing  (HAS  ME  Cl)  is  now  recognized  in  terms  of  the  known  action  PLAY: 

(UNDO  (HAS  ME  Cl)) 

8:9-11  ---  [by  RULE368.  analysis]  ---> 

(PLAY  ME  Cl) 
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The  action  description  (PLAY  ME  Cl),  combined  with  the  other  conditions,  constitutes  a  known 
specialization  of  PLAY: 

(ANO  [PLAY  ME  Cl]  [IN  Cl  (CARDS)]  [IN-SUIT  Cl  SO]) 

8:12-14  —  [by  analysis]  — > 

(PLAY-SUIT  ME  SO) 

The  resulting  plan  is  to  keep  playing  cards  from  SO  until  void  in  SO: 

(UNTIL  (VOIO  ME  SO)  (ACHIEVE  (PLAY-SUIT  ME  SO))) 

Note  that  this  plan  must  be  executed  within  the  confines  of  the  game.  Player  ME  can  only  perform 
one  step  of  the  plan  (playing  a  card  in  suit  SO)  at  each  turn,  and  only  when  SO  is  a  legal  suit  to  play. 

Actually,  the  encoded  problem  (ACHIEVE  (VOID  ME  SO) )  is  a  simplified  version  of  the  original 
natural  language  advice  “get  void,”  which  leaves  open  the  choice  of  which  suit(s)  to  get  void  in.  To 
understand  this  advice  at  a  deeper  level  one  must  appreciate  its  relation  to  other  goals  (§8.2.2)  and  the 
factors  that  affect  the  difficulty  of  implementing  it.  For  example,  getting  void  in  suit  SO  allows  player 
ME  to  sluff  (get  rid  of  potentially  undesirable  cards)  when  SO  is  led  thereafter.  This  benefit  does  not 
occur  if  no  other  player  will  lead  SO  -  for  example,  if  player  ME’s  opponents  are  already  void  in  SO. 
The  number  of  tricks  it  takes  to  get  void  in  SO  (a  measure  of  the  difficulty  of  getting  void)  is  at  least 
the  number  of  cards  player  ME  holds  in  SO,  but  is  also  affected  by  the  chances  that  another  player  will 
lead  SO  or  that  player  ME  can  do  so. 

An  interesting  problem  would  be  to  estimate  (DIFFICULTY  (ACHIEVE  (VOID  ME  SO)))  as  a 
function  of  SO.  In  particular,  it  should  be  possible  to  derive  the  fact  that  this  function  increases  with 
(#MY- CARDS- IN-SUIT  SO)  and  decreases  with  (0CARDS-OUT-IN-SUIT  SO).  Even  without 
knowing  the  exact  function,  this  Junctional  dependence  information  (§2.8)  could  be  used  to  order  suits 
according  to  the  relative  difficulty  of  getting  void  in  them. 

2.5.2.  Flushing  the  Queen 

A  subtler  use  of  the  set  depletion  strategy  occurs  in  DERIV3,  where  the  problem  is  to  devise  a  plan 
for  flushing  the  Queen  of  spades  into  the  open,  Le„  forcing  its  owner  (QSO)  to  play  it.  As  usual,  the 
derivation  begins  by  reformulating  the  initial  expression  in  terms  of  the  method: 

(FLUSH  QS) 

3:1  ---  [ELABORATE  by  RULE124]  ---> 

(MUST  (OWNER-OF  QS)  (PLAY  (OWNER-OF  QS)  OS)) 
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3:2-7  —  [by  analysis]  — > 

(«  (LEGALCAROS  (QSO))  (SET  QS ) ) ) 

3:12  ---  [ELABORATE  by  RULE340]  — > 

(AND  [SUBSET  (LEGALCAROS  (QSO))  (SET  QS)] 
[SUBSET  (SET  QS)  (LEGALCAROS  (QSO))]) 


At  this  point,  the  goal  of  flushing  the  Queen  has  been  split  into  two  subgoals.  The  first  subgoal  is 

for  (QSO)  to  have  no  legal  cards  other  than  QS,  and  the  second  is  for  QS  to  be  in  fact  legal  for  (QSO) 

to  play.  The  second  subgoal  can  be  achieved  by  making  sure  that  the  suit  led  is  spades: 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))) 

3:14-25  ---  [by  analysis]  — > 

(*  S  (SUIT-LED)) 


The  first  subgoal  is  reformulated  in  terms  of  making  a  set  empty: 

(SUBSET  (LEGALCARDS  (QSO))  (SET  QS)) 

3:37  -—  [by  RULE4]  — -> 

(EMPTY  (DIFF  (LEGALCARDS  (QSO))  (SET  QS))) 


The  rule  for  expressing  the  SUBSET  relation  in  terms  of  the  EMPTY  predicate  is: 
RULE4:  (subset  X  Y)  ->  (empty  (difFX  Y)) 


This  enables  application  of  the  set  depletion  strategy: 

(ACHIEVE  (EMPTY  (DIFF  (LEGALCARDS  (QSO))  (SET  QS)))) 

3:38  ---  [REDUCE  by  RULE6]  ---> 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE 

(REMOVE-l-FROM  (DIFF  (LEGALCARDS  (QSO))  (SET  QS))))) 


This  step  is  performed  by  the  same  rule  used  in  the  "get  void”  example: 

RUI.E6:  (achieve  (empty  S))  ->  (until  P (achieve  (remove-1- from  S))), 
where  P  is  the  original  goal 


Here.  P  =  ( PLAYED !  QS)  is  filled  in  by  the  user.  This  reflects  the  following  bit  of  goal  knowledge 
lacking  in  FOO:  the  goal  of  flushing  the  Queen  is  to  eliminate  the  risk  of  taking  it.  and  this  goal 
becomes  satisfied  as  soon  as  the  Queen  is  played,  regardless  of  whether  the  play  is  forced.  Filling  in  P 
by  hand  simulates  the  effect  of  retrieving  a  stored  explanation  of  the  reason  for  flushing  tire  Queen. 
Such  an  explanation  might  be  provided  by  the  expert  giving  the  advice,  or,  more  interestingly, 
inferred  from  the  task  description  (§8.2.3). 
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Implementing  the  set  depletion  strategy  requires  finding  an  action  that  removes  an  element  from 
the  set: 

(REM0VE-1-FR0M  (OIFF  (LEGALCARDS  (QSO))  (SET  QS))))) 

3:39-87  —  [by  analysis]  — > 

(PLAY-SPADE  (QSO)) 


Since  this  action  has  an  agent  other  than  player  ME,  a  way  is  found  to  force  it  to  happen: 

(ACHIEVE  (PLAY-SPADE  (QSO))) 

3:88-97  —  [by  analysis  of  legal  play]  — > 

(ACHIEVE  (LEAD-SPADE  ME)) 

The  final  plan  is  to  keep  leading  spades  until  the  Queen  is  played: 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))) 

Like  the  plan  for  getting  void,  this  plan  must  be  executed  within  the  structure  of  legal  play.  In 
order  to  execute  a  step  of  the  plan,  player  ME  must  be  leading  and  have  spades.  A  more  sophisticated 
treatment  of  the  advice  “flush  the  Queen”  would  deal  with  such  problems  as  getting  and  keeping  the 
lead,  and  deciding  whether  player  ME  has  enough  spades  to  execute  the  plan  to  completion.  Effective 
performance  on  these  problems  involves  the  ability  to  predict  opponents’  behavior  based  on 
knowledge  of  their  goals.  For  example,  the  players  who  don’t  have  die  Queen  are  likely  to  share  the 
goal  of  flushing  it  and  cooperate  in  leading  spades.  This  improves  the  chances  of  executing  the  plan. 

Note  that  using  (PLAYED!  QS)  its  the  termination  condition  for  the  plan  avoids  a  couple  of 
problems  associated  with  the  naive  alternative  of  terminating  when  the  event  (FLUSH  QS)  occurs. 
This  alternative  condition  is  both  non-operational  and  too  strong.  It’s  non-opcrational  because  player 
ME  can’t  generally  tell  that  player  (QSO)’s  only  legal  card  is  QS  until  after  the  fact,  say  after  (QSO) 
plays  QS  and  then  breaks  suit  next  time  spades  arc  led.  The  condition  (FLUSH  QS)  is  too  strong 
because  the  motivation  for  leading  spades  ends  as  soon  as  the  Queen  is  played,  even  if  (QSO)  has 
more  spades  left.  This  example  illustrates  the  general  phenomenon  of  goal  subsumption  [Wilcnsky 
78]:  if  the  only  purpose  of  a  goal  G1  is  to  help  achieve  a  supergoal  G2,  then  die  (possibly 
serendipitous)  attainment  of  G2  obviates  the  need  to  achieve  G2.  This  kind  of  understanding 
requires  a  representadon  of  the  relationships  between  goals,  which  I  oo  lacks  (§8.2.3). 

A  defect  of  the  derived  plan  is  that  it  allows  player  ME  to  lead  the  Ace  or  King  of  spades.  This  is  in 
fact  a  rather  effeedve  way  to  get  fhe  player  holding  the  Queen  to  play  it,  but  it  defeats  the  underlying 
purpose  of  flushing  the  Queen,  namely  to  avoid  taking  it.  The  general  principle  illustrated  here  is 
that  any  plan  for  achieving  a  subgoal  Gj  of  a  goal  G^  should  avoid  violating  G2-  When  the  goal  of 
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avoiding  taking  the  Queen  is  added  as  an  explicit  constraint  on  the  goal  of  flushing  the  Queen,  a 
modified  plan  is  derived  (§2.10). 

2.5.3.  Set  Depletion:  Summary 

Using  the  set  depiction  strategy  to  construct  a  plan  involves  the  following  steps: 

1.  Reformulate  the  goal  in  terms  of  making  a  set  empty. 

2.  Transform  (achieve  (empty  S))  into  (until  G  (achieve  ( remove- 1- from  S)»  by  RULE6,  where  G 
is  the  original  goal. 

3.  Reformulate  (remove-l-from  S)  as  an  executable  action  A. 

The  operationality  of  the  resulting  plan  depends  on  the  ability  of  the  plan  agent  to  continue 
executing  the  action  A  until  G  is  satisfied  and  to  detect  when  this  occurs. 


2.6.  Finding  Useful  Necessary  or  Sufficient  Conditions 

A  general  strategy  for  evaluating  assertions  is 

[f  you  can  7  evaluate  an  assertion  directly,  find  an  evaluable  necessary  or  sufficient  condition. 

Such  a  condition  enables  partial  evaluation  of  the  original  assertion  A  =  (P  ...):  if  a  sufficient 
condition  on  A  is  true,  A  must  be  true;  conversely,  if  a  necessary  condition  on  A  is  false,  A  must  be 
false.  Such  a  condition,  along  with  any  resuictions  on  its  applicability,  can  be  attached  to  the 
predicate  P  as  an  annotation  to  be  used  by  runtime  evaluation  mechanism. 

Similarly,  a  general  strategy  for  achieving  a  goal  is 

If  you  can  7  achieve  a  goal  directly,  find  an  achievable  necessary  or  sufficient  condition. 

Here,  “achieving  a  goal  directly"  means  translating  it  into  an  executable  action.  If  no  such  action 
corresponds  exactly  to  achieving  the  goal,  the  strategy  suggests  trying  to  solve  an  appropriate  stronger 
or  weaker  goal  instead.  Strengthening  the  goal  in  the  right  way  may  make  it  easier  to  analyze  and 
construct  a  plan  for;  a  possible  disadvantage  is  that  such  a  plan  may  be  infeasible  in  some  situations 
where  the  original  goal  could  have  been  achieved.  Weakening  the  goal  may  make  it  easier  to  achieve, 
but  doing  so  will  not  always  have  the  desired  effect  of  achieving  the  original  goal.  Thus  goal- 
weakening  is  only  effective  to  the  extent  that  the  additional  conditions  required  to  satisfy  the  original 
goal  are  likely  to  be  true. 
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As  stated  above  in  their  general  form,  these  strategies  doesn’t  tell  how  to  find  an  evaluable 
necessary  or  sufficient  condition  for  a  given  assertion  (P  ...).  l  oo  finds  possible  candidates  for 
necessary  or  sufficient  conditions  by  looking  in  its  knowledge  base  for  predicates  R  that  mention  P 
(directly  or  indirectly)  in  their  definitions.  Subsequent  logical  analysis  dcteimincs  how  to  instantiate 
R’s  arguments  and  identifies  any  restrictions  that  must  be  satisfied  for  the  instantiated  predicate  to  be 
a  necessary  (or  sufficient)  condition  on  (P ...). 

This  section  illustrates  the  first  strategy  by  means  of  three  derivations  generated  using  foo.  The 
first  derivation  finds  a  sufficient  condition  for  an  opponent  to  be  void:  the  opponent  is  breaking 
suit  (§2.6.2).  This  condition  can  be  evaluated  by  direct  observation  of  the  opponent’s  behavior.  The 
other  two  derivations  find  necessary  conditions  for  an  opponent  to  have  a  card:  the  card  must  be  out 
and  the  opponent  can’t  be  void  in  the  suit  of  the  card  (§2.6.3).  The  former  condition  can  be 
evaluated  by  remembering  which  cards  have  been  played  (§2.4.1).  The  latter  condition  is  not  always 
evaluable  but  can  be  useful  in  those  situations  where  it  is. 

* 

2.6.1.  Implicit  Decisions  to  Find  Necessary  or  Sufficient  Conditions 

There  arc  many  other  instances  in  the  derivations  where  an  expression  is  transformed  into  a 
necessary  or  sufficient  condition.  For  instance,  in  DERIV3,  the  condition  (LEGAL  (QSO)  QS)  is 
reduced  to  the  sufficient  condition  (=  (SUIT -LED)  S)  by  assuming  that  player  (QSO)  is  following. 
The  condition  would  also  be  satisfied  if  (QSO)  were  leading,  but  then  (QSO)’s  range  of  legal  cards 
would  be  less  constrained  and  hence  harder  for  player  ME  to  control.  This  example  illustrates  the 
usefulness  of  sufficient  conditons  not  just  in  evaluating  expressions  but  in  constructing  plans. 
However,  in  this  and  other  examples  the  idea  of  replacing  a  predicate  with  a  necessary  or  sufficient 
condition  is  implicit  in  the  particular  transformation  rule,  and  limited  to  a  specific  condition  rather 
than  a  collection  of  likely  candidates  found  by  searching  the  knowledge  base  of  domain  concepts.  In 
contrast,  the  rules  used  in  the  following  examples  (RULE227  and  RULE319)  express  a  general 
strategy  of  deciding  to  look  for  a  necessary  or  sufficient  condition. 

2.6.2.  A  Sufficient  Condition  for  Deducing  that  an  Opponent  is  Void 

In  DERIV11,  the  problem  of  deciding  whether  a  player  PO  is  void  in  suit  So  is  attacked  using  the 
strategy  of  looking  for  a  sufficient  condition,  expressed  by 

RULE227:  (evai(P  ...))  ->  (cval(  =  >  [R  xL ...  xnJ  [P  ...]))  if  (R  x} ...  xn)  is  true, 
where  R  is  some  predicate  with  arguments  x1 ...  x()  whose  definition  mentions  P 
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FOO  finds  a  predicate  that  mentions  VOID  in  its  definition,  namely  LEGAL  = 

(LAMBDA  (PC) 

(AND  [HAS  P  C] 

[=>  (LEADING  P) 

(OR  [CAN-LEAD-HEARTS  P]  [NEQ  (SUIT-OF  C)  H])] 

[=>  (FOLLOWING  P) 

(OR  [VOID  P  (SUIT-LED)]  [IN-SUIT  C  (SUIT-LED)])])) 


RULE227  generates  the  subproblem  of  instantiating  the  arguments  PI  and  Cl  so  as  to  satisfy 
(LEGAL  PI  Cl): 


(SHOW  (LEGAL  PI  Cl)) 

11:2  ---  [FACT  by  RULE228]  ---> 

(SHOW  (=  Cl  (CARD-OF  PI))) 

11:3-4  - [by  analysis]  — > 

(Cl  <-  BINDING  :  (CARD-OF  PI)) 

(SHOW  T) 


The  condition  (LEGAL  Pi  Cl)  is  known  to  be  true  forCl  =  (CARD-OF  PI),  i.e.,  acard  Cl  played 
by  a  player  Pi  must  be  legal  for  Pi  to  play.  This  fact  is  encoded  in  a  Hearts-specific  “fact 
rule"  (§1.3.3)  to  simulate  the  effect  of  analyzing  the  game  description: 

RULE228:  (legal  p  c)  ->  T  if  (  =  c  (card-of  p)) 

Such  an  analysis  might  proceed  by  finding  that  LEGAL  is  mentioned  (indirectly)  in  the  definition  of 
the  action  that  determines  (CARD-OF  P),  namely  PLAY-CARD  = 

(LAMBDA  (P) 

(CHOOSE  (CARD-OF  P)  (LEGALCARDS  P)  (PLAY  P  (CARD-OF  P)))) 

Thus  (CARD-OF  P)  must  satisfy  the  condition  (IN  (CARD-OF  P)  (LEGALCARDS  P)),  which 
reduces  to  (LEGAL  P  (CARD-OF  P)).  Hence  (=  C  (CARD-OF  P))  implies  (LEGAL  P  C). 

At  this  point,  the  condition  (LEGAL  PI  (CARD-OF  PI))  has  been  formulated.  It  remains  to 
determine  when  this  condition  implies  (VOID  PO  SO): 

(EVAL  (VOID  PO  SO)) 

11:1-6  ---  [by  RULE227 ,  analysis]  — > 

(EVAL  (=>  (LEGAL  PI  (CARD-OF  PI))  (VOID  PO  SO))) 


t  he  rest  of  DERIV11  consists  of  reducing  this  implication  to  an  evaluable  predicate: 

(EVAL  (*>  (LEGAL  PI  (CARD-OF  PI))  (VOID  PO  SO))) 

11  7-17  —  [oy  analysis]  — > 

31  BINDING  :  PO) 


§2.6.2.  A  Sufficient  Condition  for  Deducing  that  an  Opponent  is  Void 
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(AND  [NOT  (IN-SUIT  (CARD-OF  PO)  (SUIT-LED))] 

[=  (SUIT-LED)  SO] 

[FOLLOWING  PO]) 

11:18  ---  [RECOGNIZE  by  RULE  123 ]  ---> 

(EVAL  (AND  [BREAKING-SUIT  PO]  [=  (SUIT-LED)  SO]  [FOLLOWING  PO])) 

This  solution  says  that  a  sufficient  condition  for  player  PO  to  be  void  in  suit  SO  is  for  PO  to  be 
breaking  suit  when  the  suit  led  is  SO  and  (necessarily)  PO  is  following  rather  than  leading.  Thus  upon 
seeing  PO  break  suit,  player  ME  can  conclude  that  PO  is  void  in  the  suit  led  --  a  useful  inference  to 
remember,  since  it  remains  valid  for  the  rest  of  the  round  (§2.4). 

2.6.3.  Two  Necessary  Conditions  for  a  Player  to  Have  a  Card 

A  problem  that  arises  in  DERIV2  is  deciding  whether  it’s  possible  that  a  player  Pi  may  have  a  card 
C2  (§3.3.4),  where 

An  assertion  is  considered  possible  if  none  of  its  necessary  conditions  is  known  to  be  false. 

Thus  the  more  necessary  conditions  checked,  the  more  discriminating  the  decision  about 
possibility.  A  rule  for  finding  necessary  conditions  is 

RULE319:  (P ...)  <-;(  =  >(Q  ^  ...  X(l)  IF  R), 

for  some  predicate  Q(xL ...  xj  whose  definition  mentions  P  (perhaps  indirectly), 

where  R  is  the  result  of  simplifying  (  =  >  [P  ...]  [Q  Xl ...  xj) 

(Recall  that  the  notation  “Pj  <-;(=>  P2  IF  R)”  means  “attach  to  the  expression  P2  the  annotation 
that  P2  is  a  necessary  condition  for  P1  when  R  is  true.”) 

In  the  current  example,  (P  ...)  is  ( HAS  PI  C2 ) .  One  predicate  whose  definition  mentions  HAS  is 
OUT  =  (LAMBDA  (C)  (EXISTS  P  (OPPONENTS  ME)  (HAS  PC))) 

RULE319  accordingly  suggests  (OUT  C7)  as  a  candidate  necessary  condition  for  (HAS  PI  C2), 

where  C7  is  a  new  variable  (to  avoid  name  conflicts).  It  remains  to  solve  for  C7  and  to  determine 

when  (HAS  PI  C2)  implies  (OUT  C7): 

(=>  [HAS  PI  C2]  [OUT  C7] ) 

2:29-38  —  [by  analysis]  — > 

(C7  <-  BINDING  :  C2) 

(IN  PI  (OPPONENTS  ME)) 

Thus  (OUT  C2)  is  a  necessary  condition  for  (HAS  Pi  C2)  if  PI  is  an  opponent  of  player  ME: 
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2:28-39  —  [by  RULE319.  analysis]  — -> 

((HAS  PI  C2)  <-  ; 

(=>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME)))) 


Another  predicate  whose  definition  mentions  HAS,  albeit  indirectly,  is  NON-VOID: 
NON-VOID  =  (LAMBDA  (P)  (NOT  (VOID  P  (SUIT-LED)))) 

VOID  =  (LAMBDA  (PS) 

(NOT  (EXISTS  C  (CARDS- IN-HAND  P)  (IN-SUIT  C  S)))) 
CARDS- IN-HAND  =  (LAMBDA  (P)  (SET-OF  C  (CARDS)  (HAS  PC))) 


This  fact  is  exploited  by  RULE319  in  finding  a  second  necessary  condition  for  the  assertion 

(HAS  PI  C2).  As  before,  applying  RULE319  requires  determining  how  to  instantiate  NON-VOID 

and  figuring  out  when  the  instantiated  predicate  is  a  necessary  condition  on  the  original  assertion: 

(*>  [HAS  PI  C2]  [N0N-V0I0  P5]) 

2:41-56  —  [by  analysis]  — > 

(P5  <-  BINDING  :  PI) 

(IN-SUIT  C2  (SUIT-LED)) 


Thus  (NON-VOID  PI)  is  a  necessary  condition  for  (HAS  PI  C2)  if  C2  is  in  (SUIT-LED): 

2:40-57  ---  [by  RULE319 ,  analysis]  ---> 

((HAS  PI  C2 )  <-  ; 

(=>  (NON-VOID  PI)  IF  (IN-SUIT  C2  (SUIT-LED)))) 


2.6.4.  Finding  Necessary  or  Sufficient  Conditions:  Summary 

While  RULE227  and  RULE319  differ  in  form,  they  express  symmetric  ideas.  If  (P  ...)  is  an 
assertion  and  Q(Xj ...  xfl)  is  a  predicate  whose  definition  mentions  P  directly  or  indirectly,  then 

(Q  ...  xn)  provides  a  sufficient  condition  for  (P  ...)  when  R  is  true,  where  R  is  the  result  of 
solving  (  =  >[QXj  ...  xn]  [P  ...])  for  Xj ...  xn  and  simplifying. 

(Q  xt  ...  xn)  provides  a  necessary  condition  for  (P  ...)  when  R’  is  true,  where  R’  is  the  result  of 
solving  (  =  >  [P  ...]  [Q  Xj ...  xn])  for  Xj ...  xn  and  simplifying. 

RULE227  solves  for  x^ ...  xn  so  as  to  satisfy  (Q  Xj  ...  xr)  and  then  reduces  (P  ...)  to  the  sufficient 
condition  R.  RULF.319  solves  xL ...  xn  to  satisfy  (  =  >  (P  ...j  [Q  Xj ...  xn])  and  then  attaches  to  (P ...)  the 
annotation  that  (Q  Xj ...  xn)  is  a  necessary  condition  for  (P  ...)  when  R'  is  true.  Such  annotations  can 
be  useful  in  the  absence  of  a  systematic  way  to  compute  P. 


§2.6.4.1.  Predictors  of  Rule  Applicability 
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2.6.4.1  Predictors  of  Rule  Applicability 

There  is  an  interesting  connection  between  the  process  of  simplifying  R  and  the  restriction  that  Q’s 
definition  should  mention  P.  The  key  step  in  simplifying  R  consists  of  eliminating  the  unevaluable 
predicate  P  in  (  =  >  [Q  x:  ...  xn]  [P  ...])  or  (  =  >  [P  ...]  [Q  xt  ...  xj).  In  all  three  examples,  this  is 
accomplished  by  expanding  Q  in  terms  of  P,  and  restructuring  the  expression  into  the  form 
(...  (=>  [P  et  ...  en]  [P  ej'  ...  en’])  ...)  so  a  partial-matching  (unification)  rule  (§5.3)  can  be  applied 
(recall  that  =>  is  reflexive).  The  fact  that  a  given  predicate  Q  mentions  P  in  its  definition  is  a  clue 
(although  not  a  guarantee)  that  this  simplification  scenario  may  be  feasible. 

If  foo  had  to  find  Q  by  trial  and  error  instead  of  asking  the  user  to  select  it  from  a  list  of  predicates 
mentioning  P,  such  features  --  cheaply-computablc  predictors  of  success  -  would  be  extremely 
valuable.  How  might  they  be  discovered  automatically?  One  approach,  inspired  by  Mitchell 
[Mitchell  81]  and  Hayes-Roth  [Hayes-Roth  81b[,  would  generalize  from  successful  applications  of  a 
rule  to  scenarios  describing  their  common  structure,  such  as  the  following  scenario  for  finding  a 
necessary  condition  using  RULE319: 

1.  Choose  a  predicate  Q. 

2.  Construct  the  implication  R. 

3.  Expand  R  in  terms  of  P. 

4.  Eliminate  P  from  R. 

5.  Simplify  R. 

In  this  approach,  unsuccessful  attempts  to  use  a  rule  would  be  examined  to  find  out  where  in  the 
scenario  they  failed  --  e.g.,  couldn’t  expand  Q  in  terms  of  P.  The  original  rule  could  then  be 
specialized  to  test  for  the  property  whose  absence  led  to  failure  --  e.g.,  test  if  Q  is  expandable  to  P. 
This  test  is  potentially  expensive,  since  all  sorts  of  logical  transformations  may  be  performed  in  the 
course  of  expanding  Q.  A  cheap  substitute  is  to  test  whether  Q  mentions  P  in  its  definition.  The  new 
rule  would  constitute  improved  knowledge  about  how  to  operationalize,  since  it  would  lead  to  success 
more  often  titan  die  unconstrained  rule.  Hayes-Roth  has  suggested  a  similar  approach  to  refining 
knowledge  about  a  task  domain  based  on  analysis  of  violated  expectations  [Hayes-Roth  Sib];  die 
novel  aspect  here  is  the  idea  of  refining  knowledge  about  operationalization  in  general.  Easier  said 
than  done,  of  course. 
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2.7.  Reasoning  About  Choice 

TOO  uses  a  simple  representation  of  choice  based  on  the  quantifier  CHOOSE.  For  example,  the 
expression  (CHOOSE  (CARD-OF  P)  (LEGALCARDS  P)  (PLAY  P  (CARD-OF  P )))  represents  the 
action  “player  P  plays  a  card,  (CARD-OF  P),  chosen  from  P’s  legal  cards."  Similarly,  the  expression 
(CHOOSE  (NOTE  I)  (TONES)  (NOTE  I))  represents  “a  note,  (NOTE  I),  chosen  from  the  set 
(TONES).”  In  general,  the  construct  (choose  x  S  Ex)  means  “the  entity  Ex,  where  x  is  chosen  from  the 
set  S."  Thus  the  construct  has  the  same  type  as  the  quantified  sub-expression  Ex;  in  particular,  it  may 
denote  an  event  or  an  object  The  quantifier  variable  x  may  be  parameterized  to  distinguish  among 
similar  choices  made  at  different  points.  For  example,  (CARD-OF  P)  distinguishes  player  P’s  card 
from  the  cards  chosen  by  other  players.  Similarly,  (NOTE  I)  distinguishes  the  Ith  note  of  a  cantus 
firmus  from  the  other  notes  in  the  sequence. 

The  quantifier  CHOOSE  introduces  an  element  of  non-determinism  into  the  semantics  of  poo’s 
representation.  The  modal  operators  “necessary”  and  “possible”  can  be  used  to  form  deterministic 
predicates  from  non-detcrministic  choice-dependent  predicates: 

An  assertion  that  depends  on  a  choice  among  alternatives  is  possible  if  true  for  at  least  one 
alternative  and  necessary  if  true  for  all  alternatives. 

In  particular, 

(possible  (P  (choose  x  S  F.x)))  =  (exists  x  S  (P  Ex» 

(necessary  (P  (choose  x  S  Ex)))  =  (forall  x  S  (P  F,x)) 

Some  of  FOO’s  rules  about  choice  essentially  transform  a  choice-dependent  assertion  A  to 
(possible  A)  or  (necessary  A)  depending  on  who  makes  the  choice.  In  the  rules  shown  below,  the 
contruct  (choosc-me  x  S  Ex)  denotes  a  choice  made  by  the  agent  executing  a  plan  generated  using 
foo,  while  (choosc-other  x  S  Ex)  denotes  a  choice  made  by  another  agent.  However,  this  distinction 
is  only  implicit  in  FOO’s  actual  representation. 

1.  Constrained  choice:  (achieve  (P  (choosc-mc  x  S  Ex)))  ->  (choosc-me  x  [set-of  x  S  (P  Ex)|  Ex) 

To  achieve  a  goal  that  depends  on  something  you  choose,  choose  it  so  as  to  satisfy  the  goal. 

2.  Forcing:  (achieve  (P  (choosc-other  x  S  Ex)))  ->  (achieve  (necessary  (P  (choosc-other  x  S  Ex)))) 

To  achieve  a  goal  that  depends  on  someone  else's  choice,  make  all  his  alternatives  satisfy  it. 

3.  Pessimism:  (eval  (P  (choosc-other  x  S  Ex»)  ->  (eva!  (possible  (P  (choose-othcr  x  S  Ex)))) 
Evaluate  an  undesirable  condition  as  the  possibility  that  an  opponent  can  make  it  true. 

The  rest  of  this  section  illustrates  the  actual  or  potential  use  of  each  of  these  rules. 


§2.7.1.  Constraining  a  Choice  to  Satisfy  a  Goal 
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2.7.1.  Constraining  a  Choice  to  Satisfy  a  Goal 

Some  of  the  derivations  operationalize  goals  as  evaluable  constraints  on  a  choice  variable.  For 

example,  DERIV6  operationalizes  “avoid  taking  points”  as 

(ACHIEVE  (*>  (AND  [IN-SUIT-LED  (CARD-OF  ME)] 

[TRICK-HAS-POINTS]) 

(LOW  (CARO-OF  ME)))) 

This  expression  means  “if  you’re  following  suit  and  the  trick  has  points,  make  your  card  low.” 
(Assume  that  the  predicate  TRICK-HAS-POINTS  is  operationalized  elsewhere,  eg.,  as  a  probabilistic 
estimate  derived  using  the  disjoint  subsets  method  (§2.3)).  Here  the  value  of  the  choice  variable 
( CARD-OF  me )  is  determined  by  the  choice  event 
(PLAY-CARO  ME)  « 

(CHOOSE  (CARO-OF  ME)  (LEGALCARDS  ME)  (PLAY  ME  (CARO-OF  ME))) 

Similarly,  DERIV7  operationalizes  “get  the  lead”  as 

(ACHIEVE  (AND  [IN-SUIT-LED  (CARD-OF  ME)]  [HIGH  (CARO-OF  ME)])) 

This  plan  can  be  paraphrased  as  “make  your  card  a  high  card  in  the  suit  led.” 

Since  these  expressions  arc  (fuzzy)  predicates  on  a  choice  variable,  they  could  be  integrated  with 
other  similarly  operationalized  goals  by  means  of  an  evaluation  function.  Each  legal  choice  for 
(CARD-OF  ME)  could  be  scored  according  to  how  well  it  satisfied  each  fuzzy  predicate.  The  scores 
for  each  goal  could  be  added  together,  perhaps  weighted  by  the  relative  importance  of  the  goals  in 
the  current  game  situation  [Berliner  79].  (Knowledge  about  relative  goal  importance  would  have  to 
be  acquired  somehow,  e.g.,  from  an  expert.)  The  card  with  the  best  total  score  would  be  chosen. 

An  alternative  to  such  an  integration  mechanism  is  to  transform  constraints  on  choice  variables 
into  executable  action  descriptions,  using  the  “constrained  choice”  transformation.  To  achieve  the 
goal,  one  simply  makes  sure  to  choose  an  element  of  the  choice  set  that  satisfies  the  constraint: 

RULF156:  (achieve  P^)  ->  (choose-me  x  [set-of  y  S  P  }  E^) 
where  x  is  determined  by  the  event  (choosc-mc  x  S  H^) 

For  example,  this  transformation  can  be  applied  to  the  constraint 

(ACHIEVE  («>  (ANO  [IN-SUIT-LED  (CARD-OF  ME)] 

[TRICK-HAS-POINTS]) 

(LOW  (CARO-OF  ME)))) 
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Herex  =  (CARO-OF  ME)  is  determined  by  the  event  (PLAY-CARD  ME)  = 

(CHOOSE  (CARD-OF  ME)  (LEGALCARDS  ME)  (PLAY  ME  (CARD-OF  ME))) 

The  executable  action  produced  by  the  constrained  choice  transformation  is: 

(CHOOSE  (CARO-OF  ME) 

(SET-OF  Y  (LEGALCARDS  ME) 

(=>  (AND  [IN-SUIT-LEO  Y]  [TRICK-HAS-POINTS] )  (LOW  Y))) 

(PLAY  ME  (CARO-OF  ME))) 

This  action  description  can  be  paraphrased  as  “choose  a  legal  card  --  make  sure  it’s  a  low  card  if  it’s 
in  the  suit  led  and  the  trick  has  points  --  and  play  iL” 

Note  that  the  naming  scheme  for  choice  variables  gives  a  unique  mapping  from  a  choice  variable 
to  the  event  that  determines  it.  For  example,  the  parameterized  name  ( CARO-OF  P )  denotes  the  card 
chosen  during  the  event  (PLAY-CARD  P),  and  is  not  used  as  a  choice  variable  in  any  other  events.. 
This  distinguishes  between  cards  played  by  different  players.  Since  the  example  derivations  only 
dealt  with  one  trick  at  a  time,  it  was  unnecessary  to  disdnguish  between  cards  played  in  different 
tricks,  but  this  could  be  done  by  using  an  extra  parameter  E  to  specify  the  trick:  (CARO-OF  P  E). 

The  prerequisite  to  applying  the  constrained  choice  transformation  is  to 
Reformulate  the  original  goal  as  an  evaluable  predicate  on  a  choice  variable. 

This  is  what  constitutes  all  the  work  in  DERI  V6  and  DER1V7. 

2.7.2.  Restricting  Another’s  Options  to  Satisfy  a  Goal 

DERIV3  derives  a  plan  to  flush  the  Queen  by  eliminating  its  owner's  ether  legal  choices. 
Knowledge  about  controlling  others’  choices  is  expressed  by  the  “forcing”  transformation 

(achieve  (P  (choose-other  x  S  Ex)))  ->  (achieve  (necessary  (P  (choose-othcr  x  S  F^)))) 

If  P  has  the  form  (lambda  (x)  ( =  x  c)),  the  right  side  can  be  simplified: 

(necessary  (P  (choose-other  x  S  Ex))) 

->  (forall  x  S  (P  E  ))  --  by  definition  of  necessary 
->  (forall  x  S  ( =  fr.x  e))  --  by  definition  of  P 
->  ( =  S  {c})  --  assuming  S  is  non-empty 

This  special  case  of  the  forcing  transformation  is  given  by 


§2.7.2.  Restricting  Another’s  Options  to  Satisfy  a  Goal  79 

RULE339:  (=  [choose  x  S  (act  agent  x)[  [act  agent  objl)  ->  (=  S  {obj}) 

RULE339  generates  the  goal  of  reducing  player  (QSO)’s  legal  cards  to  the  singleton  set  {QS}: 
(ACHIEVE  (FLUSH  QS)) 

3:1-5  —  [by  analysis]  — > 

(ACHIEVE  (=  [PLAY-CARD  (QSO)]  [PLAY  (QSO)  QS])) 

3:6  —  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (=  [CHOOSE  (CARD-OF  (QSO)) 

(LEGALCARDS  (QSO)) 

(PLAY  (QSO)  (CARD-OF  (QSO)))] 

[PLAY  (QSO)  QS])) 

3:7  —  [by  RULE339]  —  > 

(ACHIEVE  (=  (LEGALCARDS  (QSO))  (SET  QS))) 

3:12-87  —  [by-set  depletion,  analysis]  — > 

(UNTIL  (PLAYED  1  QS)  (ACHIEVE  (PLAY-SPADE  (QSO)))) 

Applying  RULE339  followed  by  the  set  depletion  method  (§2.5)  reduces  the  problem  to  the 
subproblcm  of  repeatedly  forcing  player  (QSO)  to  play  a  spade.  One  might  expect  this  subproblem 
to  be  solved  by  applying  a  more  general  form  of  the  forcing  transformation,  e.g.: 

RULE339a:  Px  ->  (forall  x  S  Px),  where  x  is  determined  by  (choose-other  x  S  Ex) 

Such  a  solution  might  look  like  this: 

(ACHIEVE  (PLAY-SPADE  (QSO))) 

—  [by  finding  a  sufficient  condition]  — > 

(ACHIEVE  (=>  [PLAY-CARD  (QSO)]  [PLAY-SPADE  (QSO)])) 

—  [by  analysis]  — > 

(ACHIEVE  (SPADE!  (CARD-OF  (QSO)))) 

—  [by  RULE339a.  analysis]  — > 

(ACHIEVE  (FORALL  X  (LEGALCARDS  (QSO))  (SPADE!  X))) 

—  [by  analysis  of  LEGAL]  — > 

(ACHIEVE  (ANO  [FOLLOWING  (QSO)]  [=  (SUIT-LED)  S])) 

However,  the  rule  actually  used  in  DERIV3  to  solve  this  subproblcm  was  the  somewhat  kludgey 


RULE351:  (achieve  P)  ->  (achieve  (and  Aj ...  An)), 

where  At ...  An  arc  the  assumptions  made  in  reducing  the  original  goal  to  P 
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This  rule  enabled  communication  between  two  conjunctive  subgoals  (§5.4):  achieving  a  state  in 
which  player  (QSO)  could  legally  play  QS,  and  eliminating  (QSO)'s  other  spades.  The  conditions 
assumed  in  solving  the  first  subgoal,  Le.,  that  (QSO)  wouldn’t  be  leading  and  that  spades  would  be 
led,  sufficed  to  satisfy  the  second  subgoal  (a  fortuitous  happenstance  not  explicitly  proved  in 
DERIV3): 

(ACHIEVE  (PLAY-SPADE  (QSO))) 

3:88-89  —  [by  RULE351 ,  simplification]  ---> 

(ACHIEVE  (AND  [NOT  (LEADING  (QSO))]  [=  (SUIT-LED)  S])) 

RULE351  csscnually  compensated  for  an  inadequacy  of  POO’s  problem-solving  apparatus. 

2.7.3.  Predicting  an  Opponent’s  Choice 

The  knowledge  about  choice  described  so  far  deals  with  controlling  choices,  Le.,  achieving  goals 
that  depend  on  choices  made  by  oneself  or  someone  else.  The  same  simple  model  of  choice  is  useful 
in  predicting  choices,  Le.,  evaluating  choice-dependent  predicates.  This  is  illustrated  by  the 
“pessimistic  transformation”: 

(eval  (P  (choose-other  x  S  Ex)))  ->  (eval  (possible  (P  (choose-other  x  S  Ex)))) 

To  evaluate  an  undesirable  condition  that  depends  on  someone  else’s  choice,  assume  the  worst. 

This  assumption  is  implicit  in  the  minimax  search  method  for  game  trees  [Nilsson  71],  and 
underlies  many  countcrplanning  strategies  [Carbonell  79j.  The  pessimistic  transformation  can  be 
expressed  as  a  sort  of  dual  of  RULE339a,  e.g., 

RULF.339b:  Px  ->  (exists  y  S  P  ), 

where  Px  is  undesirable  and  x  is  determined  by  (choose-other  x  S  Ex) 

This  transformation  is  not  explicitly  used  in  the  derivations,  but  can  be  illustrated  by  a  couple  of 
hypodictical  examples.  The  first  of  these,  introduced  earlier  (§2.3).  is  the  problem  of  predicting 
whether  player  ME  will  win  the  trick  when  following  suit: 

(FORALL  Cl  ( CARDS- PLAYED- IN-SUIT )  (NOT  (HIGHER  Cl  (CARD-OF  ME)))) 

—  [by  analysis]  — > 

(FORALL  PI  (OPPONENTS  ME)  (LOWER  (CARD-OF  PI)  (CARD-OF  ME))) 

---  [by  RULE339b]  — > 

(FORALL  PI  (OPPONENTS  ME) 

(EXISTS  XI  (LEGALCARDS  PI)  (LOWER  XI  (CARD-OF  ME)))) 
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This  expression  is  still  not  operational,  but  is  easier  to  evaluate  in  the  sense  that  it  does  not  depend 
on  choices  made  by  player  ME’s  opponents,  only  on  what  cards  they  have.  It  is  consequently 
susceptible  to  evaluation  by  other  methods,  e.g.,  the  disjoint  subsets  method. 

A  similar  example  is  the  problem  of  predicting  whether  the  trick  will  have  points,  assuming  player 
ME  plays  a  card  without  points: 

(TRICK-HAS-POINTS) 

---  [ELABORATE  by  RULE124]  — > 

(EXISTS  Cl  (CAROS-PLAYEO)  (HAS-POINTS  Cl)) 

—  [by  analysis]  — > 

(EXISTS  PI  (OPPONENTS  ME)  (HAS-POINTS  (CARD-OF  Pi))) 

—  [by  RULE339b]  — > 

(EXISTS  PI  (OPPONENTS  ME) 

(EXISTS  Y1  (LEGALCAROS  PI)  (HAS-POINTS  Yl))) 

Here  the  undesirable  event  mentioned  in  RULE339b  is  (HAS-POINTS  (CARD-OF  Pi)),  where 
(CARD-OF  Pi)  is  determined  by  the  event  (PLAY -CARD  PI)  = 

(CHOOSE  (CARD-OF  PI)  (LEGALCAROS  PI)  (PLAY  PI  (CARD-OF  PI))) 

The  effect  of  applying  RULE339b  is  to  assume  that  the  trick  will  have  points  if  any  of  player  ME’s 
opponents  can  legally  play  a  point  card.  This  pessimistic  assumption  is  rather  naive,  but  a  more 
realistic  treatment  would  require  knowledge  about  players’  goals  and  behavior.  As  in  the  previous 
example,  the  expression  produced  by  RULE339b  is  non-operational  but  choice-independent  and 
susceptible  to  further  operationalization.  For  instance,  the  disjoint  subsets  method  might  be  used  to 
evaluate  the  sub-expression  (EXISTS  Yl  (LEGALCARDS  PI)  (HAS-POINTS  Yl ))  as  a  probability 
(PR-LEGAL-POINT-CARD  PI).  If  this  probability  is  assumed  independent  for  different  opponents 
Pi,  the  overall  expression  could  be  evaluated  as 

(-  1  (PRODUCT  PI  (OPPONENTS  ME)  [-  1  (PR-LEGAL-POINT-CARD  PI)])) 

2.7.4.  Model  of  Choice:  Summary 

TOO  uses  the  quantified  construct  (choose  x  S  Es)  to  represent  an  entity  Ex  involving  a  variable  x 
chosen  from  a  set  S  of  alternatives.  Quantifier  variable  names  arc  parameterized  so  as  to  distinguish 
among  choices  made  at  different  points.  The  construct  docs  not  explicitly  identify  die  agent  A 
making  the  choice,  although  it  is  an  implicit  argument  in  the  following  rules  for  achieving  or 
evaluating  conditions  involving  choice: 
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1.  Constrained  choice:  (achieve  (P  (choose  x  S  Ex)))  ->  (choose  x  [set-of  x  S  (P  Ex)]  Ex)  if  A  =  ME 
To  achieve  a  goal  that  depends  on  something  you  choose,  choose  it  so  as  to  satisfy  the  goal 

2.  Forcing:  (achieve  (P  (choose  x  S  Ex)))  ->  (achieve  (forall  x  S  (P  Ex»)  if  A  *  ME 

To  achieve  a  goal  that  depends  on  someone  else's  choice,  make  all  his  alternatives  satisfy  it. 

3.  Pessimism:  (eval  (P  (choose  x  S  Ex)))  ->  (eval  (exists  x  S  (P  Ex)))  if  A  *  ME 
Evaluate  an  undesirable  condition  as  the  possibility  that  an  opponent  can  make  it  true. 


2.8.  Approximation  based  on  Functional  Dependence 

An  underlying  problem  in  some  of  the  derivations  is  to  predict  the  probability  of  an  event,  e.g., 
that  a  given  card  will  win  the  trick,  or  to  estimate  the  probability  of  a  condition,  e.g.,  whether  an 
opponent  is  void  in  a  given  suit  Such  probabilities  may  be  affected  by  many  factors,  and 
consequently  hard  to  compute  exactly.  A  way  to  simplify  this  problem  is  to  choose  one  of  these 
factors  and  analyze  its  effect.  This  approach  underlies  the  method  of  Junctional  dependence  analysis: 

Approximate  an  expression  as  a  Junction  of  its  dependence  on  a  given  quantity. 

Although  the  examples  in  this  section  involve  probability,  the  method  itself  is  phrased  in  more 
general  terms.  It  provides  a  O^-order  approximation  for  an  expression  that  is  too  expensive  to 
compute  exactly,  or  that  can't  be  directly  evaluated  because  some  of  its  arguments  are  unavailable. 

For  example,  the  probability  of  winning  the  trick  can  be  approximated  as  a  function  of  the  rank  of 

the  card  one  plays.  This  approximation  might  be  represented  as  follows: 

(  =  (TRICK-WINNER)  ME) 

-  [by  approximation]  — > 

(FUNCTION-OF  (RANK  (CARO-OF  ME))  INCREASING) 

Here  the  construct  (function-of  v  increasing)  means  “an  increasing  function  of  v”.  Similarly, 
(function-of  v  decreasing)  means  “a  decreasing  function  of  v”. 

2.8.1.  A  Calculus  of  Functional  Dependence 

The  Junctional  dependence  of  an  expression  c  on  a  quantity  v  describes  how  e  changes  when  v 
increases:  increasing,  decreasing,  constant,  or  indeterminate.  It  is  denoted  by  the  construct 
(dependence  e  v)  and  can  be  thought  of  as  sign(3e/3v).  For  instance,  the  above  example  involves  the 
computation 
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(DEPENDENCE  [  =  (TRICK-WINNER)  ME]  [RANK  (CARO-OF  ME)]) 

—  [by  functional  dependence  analysis]  — > 

INCREASING 

The  value  of  (dependence  e  v)  is  defined  to  be  a  member,  d,  of  the  set  {0,  t,  i,  ?},  where 

d  =  NIL  (0)  if  e  stays  constant  as  v  increases 
d  =  INCREASING  (t)  if  e  increases  as  v  increases 
d  =  DECREASING  (I)  if  e  decreases  as  v  increases 
d  =  INDETERMINATE  (?)  otherwise 

The  parenthesized  symbols  will  be  used  for  abbreviation,  as  will  the  following  notation: 

(Dy  e)  =  (dependence  e  v) 

Df=(Dx(fx)) 

Df.  =  Df  =  (D  (f  x.  ...  x  ))  where  x.  ...  x  are  the  arguments  of  f 

I  x.  x  n  in 

However,  FOO  uses  the  long  form,  which  appears  in  the  derivations. 

The  four  values  (0,  t,  I,  ?}  form  a  commutative  “pseudo-ring”  with  pseudo-inverse  D-,  addition 
D+,  and  multiplication  D*  defined  as  shown  in  Figure  2-1.  A  similar  algebra  was  used  by 
DcKlcer  [DeKleer  79]  but  lacked  the  D*  operator. 

This  system  has  additive  identity  0  and  multiplicative  identity  t: 

(D+  dO)  =  d 
(D'dt)  =  d 

It  is  associative  and  commutative,  so  D  4-  and  D*  can  be  extended  to  take  n  arguments: 

(D+  d)  =  d 

(D+dj  ...dJf)  =  (D+dl(D+d2...dn)) 

(D*  d)  =  d 

(D*  dj ...  dn)  =  (D*dl(D*  d2  ...  dn)) 

It  fails  to  be  a  group  under  addition  because  1D+  d  (D-  d))  is  not  0  for  d  =  t,  i,  or  ?. 

The  following  identities  arc  useful  in  evaluating  (Dy  e)  for  a  given  expression  e: 

(Dy  (f  c))  =  (D-  (Dv  c))  if  Df  =  1,  e.g.,  (Dy  -e)  =  (D-  (Dy  e)) 

(Dy  (f  c))  =  (D*  Df  (Dy  c)),  e.g.,  (Dx  (f  (g  x)))  =  (D*  Df  Dg)  -  this  follows  from  the  chain  rule 
3(f(g.x))/3x  =  (3f/3g)(3g/3x) 
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Figure  2*1:  Calculus  of  Functional  Dependence 

(Dv  (fe1  e2))  =  (D+  (Dy  ct)  (Dy  e2))  if  Df2  =  Df2  =  t, 
e-g->  (F>v  (  +  cl  e2))  =  (D+  (Dy  e2)  (Dy  c2)) 


The  last  identity  should  be  qualified  as  follows.  If  F  is  the  space  of  functions  from  S(  to  S2,  where 
St  and  S2  arc  ordered  sets,  the  operator  Dy  is  almost  a  homomorphism  from  F  to  {0,  t,  I,  ?},  but  fails 
to  satisfy  the  identity 

(Dv(+Clc2))  =  (D+  (DyC^DyCj)) 


An  example  that  violates  this  identity  is 

(Dy  ( +  v  -v))  =  (Dy  0)  =  0  but  (D+  (Dy  v)  (Dy  -v))  =  (D+  t  4)  =  ? 

However,  Dy  does  satisfy  the  weaker  condition 
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(Dy  (+  Cj  e2))  =  (D  +  (Dy  e2)  (Dv  e2»  provided  ( D+  (Dy  c2)  (Dy  c2))  *  0 


Most  of  FOO’s  dependence  analysis  rules  are  special  cases  of  the  generalized  chain  rule 
(D  (f  e2 ...  en))  =  (D+  [D*  Dfr  (Dy  tj] ...  [D*  Dfn  (Dy  en)D 


What  is  all  this  apparatus  good  for?  The  rest  of  this  section  presents  an  explicit  example  of  its  use, 
followed  by  a  couple  of  examples  that  turn  out  to  involve  the  same  underlying  idea. 


2.8.2.  An  Example  of  Functional  Dependence  Analysis 


In  DER1V9,  the  disjoint  subsets  method  is  used  to  estimate  the  probability  that  an  opponent  PO  is 

void  in  suit  SO  as  the  quantity 

(PR-DISJOINT-FORMULA 
(iSfCARDS- IN-HAND  PO) 

(BOARDS -OUT -IN-SUIT  SO) 

(#CARDS-0UT)} 


Suppose  the  purpose  of  estimating  this  quantity  is  to  apply  the  advice 
“Avoid  leading  a  suit  in  which  someone  is  void.” 


To  choose  the  safest  suit,  one  need  not  know  the  precise  probability  of  a  void  in  each  suit;  it  is 
sufficient  to  know  which  suits  are  more  likely  than  others  to  have  voids.  Functional  dependence 
analysis  can  rank  these  probabilities  without  computing  their  numerical  values.  This  would  be  very 
useful  if  the  probability  formula  were  expensive  to  compute.  The  decision  to  apply  this  technique 
appears  in  DERIV9  as 

(EVAL  (PR-DISJOINT-FORMULA  (BOARDS- IN-HAND  PO) 

(0CAROS-OUT-IN-SUIT  SO) 

(BOARDS -OUT) ) ) 

9:44  ---  [by  RULE20Z]  — > 

(FUNCTION-OF  SO  (DEPENDENCE 

(PR-DISJOINT-FORMULA  (0CARDS- IN-HAND  PO) 

(0CARDS-OUT- IN-SUIT  SO) 

(#C ARDS -OUT)) 

SO)) 


This  decision  is  motivated  by 

RULE202:  (eval  c)  ->  (function-of  v  (Dy  e)), 
where  v  is  some  variable  in  the  original  problem 


To  implement  this  decision,  it  is  necessary  to  analyze  the  functional  dependence  involved: 


36 


§2.  Operationalization  Methods 


(DEPENDENCE  (PR-DISJOINT-FORMULA  (0CARDS-IN-HAND  PO) 

(fKCARDS-OUT- IN-SUIT  SO) 
(0CARDS-OUT)) 

SO) 

9:45-46  ---  [by  RULE203]  — -> 

(D*  (DEPENDENCE  (#CAROS-OUT-IN-SUIT  SO)  SO) 

(DEPENDENCE  (PR-DISJOINT-FORMULA  #S  MV)  iFS)) 


The  analysis  begins  by  using  the  variant  chain  rule 

RULE203:  (D  (f  ...  en»  ->  (D+  ...  [D*  Df  (Dy  Cj)) ...), 

where  the  sum  (D+  ...)  includes  a  term  for  each  e  in  which  v  occurs  (since  the  others  go  to  nil) 

Here  f=  PR-DISJOINT-FORMULA 
v  =  SO 

{*.)  =  (#h,  #s,  mv} 

(Xj  |  v  occurs  in  e;}  =  {4<S} 

This  is  followed  by  the  simplification  (D+  d)  ->  d. 

The  alert  reader  may  have  noticed  that  the  variable  SO  ranges  over  the  unordered  set  of  suits, 
rendering  expressions  like  (DEPENDENCE  (#CARDS-OUT-IN-SUIT  SO)  SO)  rather  meaningless. 
(What  is  the  partial  derivative  of  an  expression  with  respect  to  a  suit?)  This  is  now  fixed  by 
transforming  the  approximation  from  a  function  of  the  nominal  (non-numerical)  variable  SO  to  a 
function  of  the  integer-valued  expression  (0CARDS -OUT- IN-SUIT  SO): 

(FUNCTION-OF  SO 

(D*  (DEPENDENCE  (0CAROS-OUT- IN-SUIT  SO)  SO) 

(DEPENDENCE  (PR-DISOOINT-FORMULA  MV  MS  MU)  MS))) 

9:47  ---  [by  RULE210]  — -> 

(FUNCTION-OF  (0CARDS-OUT-IN-SUIT  SO) 

(D*  INCREASING 

(DEPENDENCE  (PR-DISJOINT-FORMULA  MH  MS  MU)  MS))) 

9:48  —  [by  multiplicative  identity]  — > 

(FUNCTION-OF  (0CARDS-OUT- IN-SUIT  SO) 

(DEPENDENCE  (PR-DISJOINT-FORMULA  MH  MS  MV)  MS)) 


Further  analysis  is  based  on  the  definition 

(Pr-disjoint-formula  #H  #S  #U)  = 

(tfehoose  [-  #U  #H)/(#choose  #U  #H) 


The  fact  that  x/y  is  an  increasing  function  of  x  and  a  decreasing  function  of  y  is  retrieved  from  the 
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generalization  hierarchy  (§1.3.2.1),  which  shows  that  division  belongs  to  the  category  INCR1-DECR2. 
This  justifies  the  application  of 

RULE205:  (Dy  (f  et  e2))  ->  (D+  (Dv  e2)  (D-  (Dy  e2)))  if  Df2  =  t  and  Df2  =  I 


RULE205  is  a  special  case  of  the  chain  rule: 

(DEPENDENCE  (PR-DISJOINT-FORMULA  #H  #S  #U)  #S)) 
9:50  ---  [by  RULE205]  — > 

(D+  (DEPENDENCE  (0CHOOSE  (-  HU  HS)  HU)  HS) 

(0-  (DEPENDENCE  (#CH00SE  HU  #H)  #S))) 


The  fact  that  (0CHOOSE  HU  #H)  is  independent  of  #S  permits  the  application  of 
RULE204:  (Dy  e)  ->  nil  if  v  does  not  occur  in  e  (assuming  e  doesn’t  expand  to  v) 


This  leads  to  some  simplification: 

(DEPENDENCE  (^CHOOSE  HU  ifH)  HS) 

9:51  ---  [EVAL  by  RULE204]  ---> 

NIL 

(D-  NIL) 

9:52  ---  [COMPUTE  by  RULE236]  — > 

NIL 

(D+  (DEPENDENCE  (0CHOOSE  (-  #U  HS)  #H)  HS)  NIL) 
9:53  ---  [SIMPLIFY  by  RULE343]  ---> 

(DEPENDENCE  (^CHOOSE  (-  HU  HS)  HH)  HS) 


The  fact  that  D#  choose  t  =  t  (Le.,  (#  choose  n  k)  increases  with  n)  is  encoded  as  an  is-a  link  from 

#CHOOSE  to  INCR1.  This  fact  justifies  the  reduction 

(DEPENDENCE  (0CHOOSE  (-  HU  HS)  0H)  HS) 

9:54  —  [REDUCE  by  RULEZ07]  ---> 

(DEPENDENCE  (-  HU  HS )  HS) 


This  step  uses  another  special  case  of  the  chain  rule: 

RULE207:  (Dy  (f  e1 ...  en))  ->  (Dy  e2)  if  =  t  and  v  does  not  occur  in  e2 ...  en 


Subtraction  is-a  INCR1-DECR2,  so  RULF.205  is  applied  once  again: 

(DEPENDENCE  (-  HU  HS)  HS) 

9:55  ---  [by  RULE205]  — -> 

(0+  (DEPENDENCE  HU  HS)  (D-  (DEPENDENCE  0S  #S ) ) ) 
9:56-59  —  [by  RULE204,  simplification]  — > 

(D-  (DEPENDENCE  0S  HS)) 


The  fact  that  any  quantity  is  an  increasing  function  of  itself  is  encoded  in 
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« 


RULE208:  (Dyv)->t 

This  fact  is  used  in  completing  the  functional  dependence  analysis: 

(D-  (DEPENDENCE  #S  #S)) 

9:57  —  [EVAL  by  RULE208,  simplification]  ---> 

DECREASING 

2.8.3.  Application:  Ordering  a  Choice  Set 

The  final  approximation  derived  for  (VOID  PO  SO)  is 

(FUNCTION-OF  (0CAROS-OUT- IN-SUIT  SO)  DECREASING) 

This  expression  could  be  used  to  order  the  suits  according  to  the  estimated  riskiness  of  leading 
them.  A  simple  way  to  do  this  is  to  define 

(fimetion-of  vd)=+vifd  =  t 
(function-of  v  d)  =-v  if  d  =  I 
(fimetion-of  v  d)  =0  otherwise 

A  refinement  normalizes  the  range  to  be  [0,11: 

(function-of  vd)  =  (v  -  v  .  )  /  (vm„.  -  v.) 

'  '  '  min'  max  min' 

Computing  the  normalized  function  would  require  determining  vmm  and  v^;  a  different 
normalization  scheme  would  be  required  if  either  of  these  were  infinite.  In  any  case,  the  function  of 
v  thus  constructed  could  be  used  as  a  term  in  an  evaluation  function  used  to  order  the  choice  set  of 
legal  cards  (§2.7.1). 

2.8.4.  Analysis  Combined  with  Experience 

An  interesting  application  of  functional  dependence  analysis  would  be  possible  in  a  system  with 
mechanisms  not  only  for  taking  advice  but  for  learning  from  its  own  experience.  Instead  of  using  a 
linear  function  of  v  as  a  O^-ordcr  approximation  of  the  original  expression  c,  the  task  agent  could 

Compile  a  table  of  the  actual  values  of  e  encountered  for  each  value  of  v. 


« 


In  the  earlier  example  (§2.8.2),  this  would  mean  keeping  track  of  how  often  an  opponent  turned 
out  to  be  void  when  a  given  number  of  cards  in.  the  suit  were  still  out.  (Note  that  this  approach 
requires  a  way  to  evaluate  c,  although  it  may  be  evaluated  after  the  fact,  i.e.,  after  the  situation  where 
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the  value  of  e  was  needed.)  Given  enough  data,  the  system  would  eventually  develop  a  good 
empirical  estimate  of  the  probability  of  a  void  as  a  function  of  the  number  of  cards  out  in  the  suit 
Human  players  appear  to  acquire  knowledge  of  game  probabilities  by  a  similar  process;  it  seems  hard 
otherwise  to  explain  how  they  discover  heuristics  like 

A  suit  is  generally  safe  for  the  first  two  tricks  in  which  it’s  led. 

The  approach  advocated  here  is  to 

Use  dependence  analysis  to  identify  potential  predictors  of  important  events  and  conditions,  and 

determine  their  predictive  strength  empirically. 

This  approach  should  help  reduce  the  combinatorics  inherent  in  “bottom-up”  discovery  of  such 
predictors  or  criterial  features  of  the  task  domain,  while  avoiding  the  often  intractable  task  of 
computing  their  predictive  strength  analytically.  /.<?.,  analysis  may  guide  empirical  discovery. 

2.8.5.  Extensions 

DF.RIV9  is  the  only  derivation  involving  the  explicit  use  of  functional  dependence  analysis.  The 
same  technique  could  be  used  to  approximate  other  expressions  (not  just  probabilities!)  as  functions 
of  observable  quantities.  For  example,  the  expected  number  of  points  in  a  trick  could  be  estimated  as 
a  function  of  the  number  of  points  still  out: 

(^POINTS- IN-TRICK) 

—  [by  RULE202,  functional  dependence  analysis]  — > 

(FUNCTION-OF  (#POINTS-OUT)  INCREASING) 

An  extension  of  the  method  would  approximate  an  expression  as  a  function  of  n  quantities: 

e  ->  (function-of  (Dy  e) ...  vn  (Dy  e)) 

1  n 

For  example,  a  better  estimate  for  the  expected  number  of  points  in  a  trick  might  be  given  by 

(FUNCTION-OF  (0POINTS-OUT)  INCREASING 

(#C ARDS -OUT- IN-SUIT- LED)  DECREASING) 

The  n-ary  function  might  be  computed  as  a  linear  combination  of  Vj ...  vfl,  or  as  an  n-dimcnsional 
tables  containing  empirically  determined  values  of  e  for  different  values  of  v1 ...  v  . 
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2.8.6.  Generality 

The  rules  used  in  DERIV9  included  some  ad  hoc  specializations  of  the  generalized  chain  rule: 
RULE205:  (Dy  (fe1  e2))  ->  (D+  (Dy  ei) (D-  (Dy  e2)))  if Df2  =  t  and  Df2  =  i 
RULE207:  (Dy  (f  e2 ...  en))  ->  (Dy  e2)  if  Dfx  =  t  and  v  does  not  occur  in  e2 ...  en 

These  specialized  rules  served  to  shorten  the  derivation  by  avoiding  consideration  of  several  terms 
that  would  have  reduced  to  nil.  A  more  efficient  implementation  might  use  a  systematic  procedure 
for  dependence  analysis,  based  on  the  generalized  chain  rule. 

2.8.7.  Implicit  Dependence  Analysis 

A  second  look  at  the  “avoid  taking  points”  example  reveals  the  underlying  idea  of  functional 
dependence.  In  DER1V6,  the  goal  (AVOIO-TAKING-POINTS  (TRICK))  is  reformulated  as  a 
condition  containing  the  sub-expression 

(EXISTS  XI  (CARDS- PLAYED- IN-SUIT- LED)  (LOWER  (CARD-OF  ME)  XI)) 

Since  the  set  (CARDS -played- IN-SUIT -LED)  is  generally  unknown  when  (CARD-OF  ME)  is 
chosen,  this  sub-expression  is  approximated  as  the  fuzzy  condition  ( LOW  (CARD-OF  ME ) )  by 

RULE154:  (R  e2  e2)  ->  (P  Cj),  where  R  is  the  comparative  form  of  predicate  P 

An  alternative  version  of  this  derivation  would  be 

(AVOID- TAKING- POINTS  (TRICK)) 

---  [by  RULE202]  — > 

(FUNCTION-OF  (CARD-OF  ME) 

(DEPENDENCE  (AVOIO-TAKING-POINTS  (TRICK)) 

(CARD-OF  ME))) 

—  [by  RULE210,  functional  dependence  analysis]  — > 

(FUNCTION-OF  (LOW  (CARD-OF  ME))  INCREASING)  ■ 

Thus  RULE154  can  be  expressed  in  functional  dependence  notation  as  the  approximation  rule 
(R  e2  c2)  ->  (function-of  (P  e2)  increasing) 


RULE154  is  also  used  in  the  course  of  constructing  a  plan  to  get  the  lead: 
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(ACHIEVE  (LEADING  ME)) 

7:1-7  —  [by  analysis.  RULE154]  ---> 

(ACHIEVE  (AND  [IN-SUIT-LED  (CARD-OF  ME)] 

[NOT  (LOW  (CARD-OF  ME))])) 

Explicit  functiona1  dependence  analysis  might  produce  this  essentially  similar  solution: 

(ACHIEVE  (LEADING  ME)) 

—  [by  RULE210,  functional  dependence  analysis]  — > 

(FUNCTION-OF  (RANK  (CARD-OF  ME))  INCREASING) 

2.8.8.  Functional  Dependence  Analysis:  Summary 

An  alternative  to  evaluating  an  expression  e  is  to  analyze  its  functional  dependence  on  some  known 
quantity  v,  using  a  simple  calculus  of  4  elements  {t,  4,  0,  ?}.  Since  this  technique  requires  less 
information  than  direct  evaluation,  it  may  be  applicable  when  some  of  c’s  arguments  are  unknown,  or 
when  e  is  too  expensive  to  compute.  It  gives  a  way  to  order  a  set  (ey  |  v  in  V}  in  terms  of  an  ordering 
on  the  set  V,  without  actually  evaluating  ey  for  each  v. 

2.9.  Simplifying  Assumptions 

A  problem  can  be  made  easier  to  solve  by  making  suitable  assumptions.  Some  strategies  for 
making  assumptions  include: 

Assume  that  an  unlikely,  undesirable,  or  complicating  condition  is  false. 

Assume  that  a  desirable  and  plausible  condition  is  true. 

If(f  e)  is  difficult  to  evaluate,  but  (f  x)  =  c  for  most  x  in  the  domain  of  f.  assume  (fe)  =  c. 

2.9.1.  Implicit  Simplifying  Assumptions 

The  derivations  use  many  implicit  assumptions  of  the  form  “assume  this  transformation  preserves 
semantic  equivalence.”  For  instance,  consider  the  partial  matching  rule 

RULF.43:  (R  (f  et ...  c^ffc^...  en’)) ->  (and  [=  c1c1’]...[=  en  en'])  if  R  is  reflexive 

This  rule  preserves  logical  equivalence  (is  valid)  assuming  certain  conditions  on  R  and /(§5.3.3).  In 
particular,  the  function  f  must  be  injective,  Le.,  produce  a  different  value  for  every  distinct 
combination  of  values  to  which  it’s  applied.  Otherwise,  RULE43  is  only  sound.  ie„  its  right  hand 
side  implies  its  left  hand  side  but  the  converse  may  not  hold.  The  derivations  often  implicitly  assume 
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RULE43,  and  various  other  rules,  to  be  valid.  This  corresponds  to  assuming  certain  sometimes  subtle 

properties  of  the  task  domain.  For  example,  one  step  in  reformulating  the  advice 

(AVOID  (TAKE-POINTS  HE)  (TRICK) ) as (ACHIEVE  (LOW  (CARD-OF  ME)))  is: 

(DURING  [TAKE  (TRICK-WINNER)  C3]  [TAKE  ME  Cl]) 

6:11  ---  [REOUCE  by  RULE43]  — -> 

(AND  [=  (TRICK-WINNER)  ME]  [*  C3  Cl]) 

To  assume  that  this  transformation  preserves  logical  equivalence  is  to  assume  that  only  one  TAKE 
event  can  occur  at  a  time.  The  significance  of  implicit  rule  validity  assumptions  as  a  form  of 
knowledge  about  the  task  domain  is  discussed  further  in  (§6.4). 

In  contrast,  this  section  discusses  the  use  of  explicit  assumptions  in  evaluating  expressions  and  in 
constructing  plans  to  achieve  goals.  It  gives  examples  of  how  to  make,  retrieve,  and  apply  them. 

2.9.2.  Assumptions  in  Planning 

A  useful  strategy  in  achieving  a  goal  is  to 

Treat  an  assumption  made  in  constructing  a  plan  as  an  additional  subgoal. 

For  instance,  in  DERIV3,  a  subgoal  of  flushing  the  Queen  of  spades  is  to  make  it  legal  for  the 
player  (QSQ)  who  has  the  Queen  to  play  it.  The  real  problem,  not  represented  explicitly,  is  to  satisfy 
this  subgoal  as  narrowly  as  possible,  Le„  make  the  Queen  one  of  a  small  set  of  legal  options.  If  player 
(QS0)  is  leading,  he  or  she  can  play  almost  any  card.  Since  the  goal  is  to  control  (QSO)’s  choice  of 
card,  the  case  in  which  (QSO)  is  following  is  more  promising.  This  reasoning  is  based  on  a  general 
strategy  (used  elsewhere  in  counter-planning  [Carbonell  78J): 

To  control  a  choice  made  by  someone  else,  narrow  the  range  of  alternatives. 

It  uses  the  specific  Hearts  knowledge  that 

A  player’s  range  of  legal  cards  is  usually  narrower  when  following  than  when  leading. 

The  latter  empirical  fact  is  rather  hard  to  prove  rigorously  from  the  ailes  of  the  game,  since  it 
depends  on  the  relative  frequency  of  exceptions,  such  as  when  a  player  has  lots  of  hearts  but  can’t 
lead  them  because  hearts  haven’t  been  broken  yet.  However,  the  same  plan  can  still  be  discovered 
without  knowing  this  fact.  Consider  the  goal 
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(LEGAL  (QSO)  QS) 

3:20-25  —  [by  analysis]  — > 

(AND  [*>  (LEADING  (QSO)) 

(OR  [CAN -LEAD- HE ARTS  (QSO)] 
[NEQ  (SUIT-OF  QS)  H])] 
[*>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[»  S  (SUIT-LED)])]) 


The  case  where  (QSO)  is  following  involves  the  condition  (=  S  (SUIT-LED)).  Making 
(SUIT-LED)  spades  is  a  significant  restriction,  since  ( SUIT -LED)  can  take  on  any  of  four  values: 

(#  (RANGE  SUIT-LED))  =  (#  (SUITS))  =  4 


The  derivation  therefore  proceeds  by  assuming  this  restriction,  as  suggested  by 
RULE342:  ( =  c  e)  ->  assume  e  =  c,  where  c  is  a  constant 


As  implemented,  RULE342  does  not  try  to  compute  the  range  of  f  in  (=  c  (f ...)).  The  decision  to 
apply  RULE342  here  reflects  my  knowledge  of  Hearts.  The  same  decision  might  be  made 
mechanically  by  trial  and  error:  in  the  alternative  case,  player  ( QSO )  leads  and  need  not  play  QS. 


The  assumption  that  spades  are  led  suffices  to  achieve  the  subgoal  (LEGAL  (QSO)  QS): 


3:26-34 


(*>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[=>  S  (SUIT-LED)])) 

—  [by  RULE342,  analysis]  — > 
T 


ASSUMING  (SUIT-LED)  =>  S 


Later  in  DERIV3,  the  set  depletion  method  (§2.5)  is  applied  to  the  subgoal  of  making  the  Queen 

of  spades  player  (QSO)’s  only  legal  card: 

(SUBSET  (LEGALCARDS  (QSO))  (SET  QS)) 

3:37-38  ---  [by  RULE6 ,  analysis]  -> 

(UNTIL  ( PLAYED1  QS) 

(ACHIEVE 

(REM0VE-1-FR0M  (DIFF  (LEGALCARDS  (QSO))  (SET  QS))))) 

3:39-61  —  [by  analysis]  — > 
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(UNTIL  (PLAYED!  QS ) 

(ACHIEVE  (ANO  [PLAY  (QSO)  C3] 

[=>>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 
[NEQ  (SUIT-OF  C3)  H])] 

[*>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[IN-SUIT  C3  (SUIT-LED)])] 
[IN  C3  (OIFF  (CAROS)  (SET  QS))]))) 


This  expression  is  simplified  by  substituting  S  for  (SUIT -LED)  based  on  the  earlier  assumption: 

(=>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 

[IN-SUIT  C3  (SUIT-LED)])) 

3:62-79  ---  [by  RULE346 ,  analysis]  — > 

(=>  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)) 


The  rule  for  substitution  based  on  an  assumed  equality  is 
RULE346:  e  ->  c  if  e  =  c  was  assumed  earlier 


Steps  3:64-77  of  the  analysis  eliminate  the  impossible  clause  (VOID  (QSO)  S). 


The  problem  is  complicated  by  the  case  (LEADING  ( QSO ) },  so  this  case  is  assumed  to  be  false: 

(=>  (LEADING  (QSO)) 

(OR  [CAN-LE AO- HEARTS  (QSO)] 

[NEQ  (SUIT-OF  C3 )  H])) 

3:80  ---  [ASSUME  by  RULE349]  ---> 

T 

ASSUME  (LEADING  (QSO))  =  NIL 


This  assumption  illustrates  the  general  strategy 

Assume  that  an  unlikely,  undesirable,  or  complicating  condition  is  false. 


In  this  instance  the  strategy  is  expressed  by 

RULF.349:  ( =  >  P  Q)  ->  T  plus  the  assumption  that  P  is  false, 
where  P  is  a  case  you’d  like  to  rule  out 


Here  I  played  the  role  of  problem-solver  and  identified  the  case  to  be  ruled  out:  FOO  has  no  way  to 
do  so  itself.  The  assumption  serves  to  simplify  the  remaining  case: 

(=>  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)) 
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3:83 

(FOLLOWING  (QSO)) 

---  [ELABORATE  by  RULE124]  ---> 

3:84-85. 

(NOT  (LEADING  (QSO))) 

-  [EVAL  by  RULE346,  analysis]  - > 

T 

3:86 

(=*>  T  (IN-SUIT  C3  S)) 

---  [SIMPLIFY  by  RULE12]  — > 

(IN-SUIT  C3  S) 

Both  assumptions  are  then  adopted  as  subgoals: 

(ACHIEVE  (PLAY-SPADE  (QSO))) 

3:88  ---  [by  RULE351]  — -> 

(ACHIEVE  (AND  [  =  (LEADING  (QSO))  NIL]  [=  (SUIT-LED)  S])) 

This  step  is  suggested  by  the  slightly  kludgcy  rule 

RULE351:  (achieve  P)  ->  (achieve  (and  Pj ...  Pn)), 

where  P1 ...  Pn  arc  the  assumptions  made  in  reducing  the  original  goal  to  P 

The  kludge  is  the  assumption  that  PL  ...  Pn  are  sufficient  to  guarantee  P,  Le..  that  RULE351  is 
sound.  If  not,  it  may  lead  to  a  plan  that  doesn’t  always  achieve  the  original  goal  (§2.6).  Here, 
however,  satisfying  the  two  subgoals  is  adequate  to  make  player  (QSO)  play  a  spade.  The  eventual 
plan  is: 

(UNTIL  ( PLAYED  1  QS)  (PLAY-SPADE  ME)) 

As  mentioned  elsewhere,  this  plan  is  only  partly  operational,  since  in  order  to  execute  it  player  ME 
must  have  the  lead  and  enough  spades  to  last  until  player  (QSO)  is  forced  to  play  QS.  The  point  of 
the  example,  however,  is  to  illustrate  how  assumptions  arc  made,  retrieved,  and  applied  in  constructing 
the  plan.  The  assumptions  that  spades  arc  led  and  that  (QSO)  is  following  arc  made  on  the  basis  of 
general  rules  for  making  simplifying  assumptions.  Assumptions  of  the  form  <exprcssion>  = 
<constant>  are  retrieved  when  the  <expression>  shows  up  elsewhere  in  the  problem,  and  are  applied  to 
simplify  the  problem  by  substituting  the  <constant>  for  the  <expression>.  Finally,  the  assumptions 
are  adopted  as  subgoals,  whose  solution  gives  a  plan  for  achieving  the  original  goal. 

2.9.2.1  Applications  of  Planning  Assumptions 

Assumptions  made  in  planning  can  be  used  in  several  ways.  One  represented  by  RULE351  is  to 
Incorporate  the  assumption  as  a  subgoal. 

For  instance,  the  ability  of  player  ME  to  determine  the  suit  led  generally  requires  that  player  ME  be 
the  leader.  This  condition  can  added  to  the  plan  for  flushing  the  Queen  as  a  subgoal: 
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Gel  the  lead  and  play  a  spade. 

An  alternative  to  satisfying  the  assumptions  as  part  of  a  plan  is  to 

Incorporate  the  assumption  as  a  restriction  on  the  applicability  of  the  plan. 

Thus  having  the  lead  can  be  taken  as  a  precondition  of  the  plan  for  flushing  the  Queen: 

If  you  're  leading,  play  a  spade. 

A  third  possibility  is  useful  when  a  plan  involves  an  uncertain  contingency.  A  simple  way  to  deal 
with  this  is  to 

Assume  the  contingency  will  occur  and  plan  accordingly. 


This  idea  is  discussed  in  (§2.9.2.2). 


19.2.2  Contingency  Planning 


The  contingency  planning  approach  is  illustrated  in  DERIV5.  where  the  plan  for  flushing  the 
Queen  is  modified  to  avoid  taking  it  in  die  process.  This  is  done  by  assuming  the  Queen  will  be 
played  and  planning  accordingly: 

(AND  [ACHIEVE  (FLUSH  QS)]  [AVOID  (TAKE  ME  QS)  (TRICK)]) 

5:1-35  —  [by  RULE301 ,  analysis]  -— > 

(UNTIL  ( PLAYED1  QS) 

(ACHIEVE  (AND  [LEAD-SPADE  ME] 

[=>  [IN  QS  (CARDS-PLAYED)] 

[EXISTS  XI  ( CARDS-PLAYED- IN -SUIT -LED) 

(HIGHER  XI  (CARD-OF  ME))]]))) 


This  expression  can  be  paraphrased  as 

Lead  spades  until  the  Queen  is  played  -  but  when  the  Queen  is  played,  make  sure  your  card 
isn’t  the  winning  card  (highest  card  played  in  the  suit  led). 


Playing  a  card  lower  than  the  Queen  will  suffice  to  keep  player  ME  from  winning  the  trick  if  the 
Queen  is  played: 

(=>  [IN  QS  (CAROS-PLAYED)] 

[EXISTS  XI  ( CARDS -PLAY ED- IN- SUIT -LED) 

(HIGHER  XI  (CARD-OF  ME))]) 

5:39-49  ---  [by  RULE84,  analysis]  — -> 

(=>  [IN  QS  (CAROS-PLAYED)] 

[HIGHER  QS  (CARD-OF  ME)]) 
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Player  ME  can't  generally  predict  when  the  Queen  wiil  be  played.  Contingency  planning  is 

reflected  in  the  decision  to  assume  it  will  be  played  in  the  current  trick: 

(  =  >  [IN  QS  (CARDS-PLAYED)] 

[HIGHER  QS  (CARD-OF  ME)]) 

5:50  ---  [by  RULE  157 ]  ---> 

(HIGHER  QS  (CARD-OF  ME)) 


This  assumption  is  suggested  by  the  converse  of  RULE349: 

RULE157:  ( =  >  P  Q)  ->  Q,  where  Q  is  a  goal  and  P  is  an  uncertain  contingency 


The  simplification  based  on  this  assumption  leads  to  the  plan 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SAFE-SPADE  ME))) 


2.9.3.  Assumptions  in  Evaluation 

So  far,  the  discussion  of  simplifying  assumptions  has  focussed  on  their  use  in  planning.  A  suitable 
assumption  can  also  be  used  to  simplify  an  evaluation  problem,  at  the  cost  of  producing  an  inaccurate 
value  when  the  assumption  is  wrong: 

Approximate  an  expression  by  making  a  suitable  assumption. 

If  the  assumption  is  one  whose  truth  can  be  relative,  e.g.,  “the  cards  arc  randomly  distributed."  the 
accuracy  of  the  value  may  depend  on  the  degree  to  which  the  assumption  is  satisfied.  The  tradeoff  of 
accuracy  for  simplicity  can  be  worthwhile,  especially  if  die  original  expression  is  hard  to  analyze.  The 
trick,  of  course,  is  finding  a  “suitable  assumption.” 


An  example  of  such  an  assumption  is  the  decision  in  D1ZRIV10  to  ignore  the  hole  card  when 

computing  the  number  of  cards  out  in  suit  SO.  Before  this  decision,  this  number  has  been  shown  to 

be  the  number  that  were  out  when  the  round  started,  minus  those  no  longer  out: 

(EVAL  (#C ARDS -OUT- IN -SUIT  SO)) 

10:1-12  ---  [by  RULE370,  analysis]  — > 

(EVAL  (-  (it  (SET-OF  XI  ( CARDS- IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND- IN- PROGRESS)  (OUT  XI)))) 

(#  (SET-OF  XI  ( CARDS- IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND- IN- PROGRESS ) 

(UNDO  (OUT  XI))))))) 


To  compute  the  number  of  cards  out  at  the  start  of  the  round,  the  pigeon-hole  principle  is  used, 
plus  the  fact  that  the  deck  and  pot  are  empty  when  the  round  begins: 


98 


§2.  Operationalization  Methods 


(BEFORE  (CURRENT  ROUND- IN- PROGRESS)  (OUT  XI)))) 
10:14-18  ---  [by  RULE301,  analysis]  — > 

(OR  [BEFORE  (CURRENT  ROUNO-IN-PROGRESS) 

(AT  XI  HOLE)] 

[BEFORE  (CURRENT  ROUND-IN-PROGRESS) 

(HAS  ME  XI)]) 


At  this  point,  the  problem  is  simplified  by  assuming  the  hole  card  wasn’t  in  the  suit  led: 

(AT  XI  HOLE) 

---  [ASSUME  by  RULE373]  — -> 

NIL 

—  [by  analysis]  — > 

(BEFORE  (CURRENT  ROUNO-IN-PROGRESS) 

(HAS  ME  XI)) 


This  assumption  is  generated  by  the  Hearts-specific  rule 
RULE373:  (at  card  hole)  ->  nil  by  assumption 


It  is  based  on  the  knowledge  that  any  given  card  is  unlikely  to  be  the  hole  card.  (Note  that  the 
plausibility  of  this  assumption  is  compromised  by  quantification  over  XI ;  however,  it’s  not  entirely 
invalidated  if  the  scope  of  quantification  covers  a  reasonably  small  fraction  of  the  set  of  cards.  In  this 
example,  the  quantifier  covers  a  fourth  of  the  cards.)  A  more  general  rule  would  be 

RULE373a:  P  ->  nil  by  assumption  if  P  is  unlikely 


However,  this  would  require  the  ability  to  estimate  (Pr  P),  or  at  least  to  verify  (unlikely  P). 


An  even  more  general  version  of  RULE373a  is  the  strategy 

RULE373b:  If(fe)is  difficult  to  evaluate,  but  (f  x)  =  c  for  most  x  in  the  domain  of  f,  assume 
(fe)  =  c. 


In  this  example,  f  =  (lambda  (C)  (AT  C  HOLE) ),  which  is  nil  for  all  but  one  card. 


2.9.4.  Simplifying  Assumptions:  Summary 


Simplifying  assumptions  can  be  very  useful  in  both  planning  and  evaluation.  A  suitable 
assumption  may  help  reduce  an  expression  to  a  simpler  one,  or  even  to  a  constant,  typically  by 
replacing  a  sub-expression  with  its  assumed  value.  The  assumption  can  then  be  treated  as  a  subgoal, 
as  a  plan  contingency,  or  as  a  restriction  on  the  applicability  of  the  solution.  Alternatively,  it  can  be 
kept  as  an  untested  condition  whose  violation  may  occasionally  invalidate  the  solution. 


10:19 

10:20-21 
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2.10.  Combining  Interdependent  Constraints 

This  section  discusses  strategies  for  operationalizing  conjunctions  of  goals.  As  such,  it  touches  on 
the  issue  of  integration  (§8.2.2),  which  has  otherwise  been  excluded  as  beyond  the  scope  of  the 
dissertation. 

2.10.1.  Using  an  Assumption  Made  in  Planning 

A  common  problem  in  constructing  plans  to  achieve  multiple  goals  arises  when  the  goals  interact. 
For  example,  consider  the  two  goals  generated  in  DERIV3  in  the  course  of  constructing  a  plan  to 
flush  the  Queen  of  spades: 

(ACHIEVE  (AND  [SUBSET  (LEGALCARDS  (QSO) )  (SET  QS)] 

[SUBSET  (SET  QS)  (LEGALCARDS  (QSO))])) 

The  second  goal  is  to  make  the  Queen  a  legal  card  for  the  player  who  has  it.  This  goal  is  easily 
satisfied  if  that  player  has  the  lead.  However,  that  makes  it  difficult  to  satisfy  the  first  goal  of 
eliminating  the  player’s  other  legal  cards. 

One  approach  to  this  problem  is 

Record  the  assumptions  made  in  solving  one  goal  and  apply  them  to  the  others. 

Assumptions  in  FOO  have  the  form  <exprcssion>  =  <value>  and  are  applied  by  substituting 
<valuc>  for  instances  of  <cxpression>  occurring  in  the  other  goals  (§5.4.3). 

The  example  is  solved  by  reducing  the  second  goal  to  the  assumption  that  spades  are  led: 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))) 

3:14-35  —  [by  RULE342 ,  analysis]  — > 

T 

ASSUMING  (SUIT-LED)  =  S 

This  assumption  is  used  to  simplify  the  first  goal.  First  the  goal  is  expanded: 

(ACHIEVE  (SUBSET  (LEGALCARDS  (QSO))  (SET  QS))) 

3:37-43  —  [by  RULE6,  analysis]  — > 

(UNTIL  (PLAYE01  QS) 

(ACHIEVE  (AND  [UNDO  (LEGAL  (QSO)  C3 ) ] 

[IN  C3  (DIFF  (CARDS)  (SET  QS))]))) 


(LEGAL  (QSO)  C3) 
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—  [ELABORATE  by  RULE124]  ---> 

(ANO  [HAS  (QSO)  C3] 

[  =  >  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 
[NEQ  ( SUIT-OF  C3)  H])] 

[»>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[IN-SUIT  C3  (SUIT-LED)])]) 


The  assumption  is  applied  by  plugging  in  S  as  the  value  of  (SUIT -LED): 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[IN-SUIT  C3  (SUIT-LED)])]) 

3:62-79  —  [by  RULE346 ,  analysis]  --> 

(IN-SUIT  C3  S) 


This  substitution  is  performed  by  a  rule  discussed  previously  (§2.9): 
RULE346:  e  ->  c  if  e  =  c  was  assumed  earlier 


2.10.2.  Modifying  a  Plan 


Another  technique  for  integrating  two  goals  is 

Construct  a  plan  to  achieve  one  goal  and  modify  it  to  achieve  the  other. 


This  approach  is  illustrated  in  DF.RIV5,  where  the  problem  is  to  flush  the  Queen  without  taking  it. 
The  derivation  starts  by  plugging  in  the  plan  derived  in  DERIV3  for  flushing  the  Queen: 

(AND  [ACHIEVE  (FLUSH  QS)]  [AVOID  (TAKE  ME  QS)  (TRICK)]) 

5:1  ---  [REDUCE  by  RULE301]  ---> 

(AND  [UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))] 

[AVOID  (TAKE  ME  QS)  (TRICK)]) 

5:2-4  —  [by  RULE124,  restructuring]  — > 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE 

(AND  [LEAD-SPAOE  ME] 

[NOT  (DURING  (TRICK)  (TAKE  ME  QS))]))) 
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Next  “avoid  taking  the  Queen'’  is  reformulated  as  a  condition  on  (CARD-OF  ME): 
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5:5-31  —  [by  analysis]  — > 

(UNTIL  ( PLAYED  1  QS) 

(ACHIEVE 

(AND  [  =  (LEADER)  ME] 

[SPADE!  (CARD-OF  ME)] 

[NOT  (ANO  [IN  QS  ( CARDS-PLAYED) ] 

[*  (SUIT-OF  (CARD-OF  ME)) 

(SUIT-OF  (CARD-OF  (LEADER)))] 

[FORALL  XI 

(CARDS- IN- SUIT -LED  (CARDS-PLAYED)) 
(NOT  (HIGHER  XI  (CARD-OF  ME)))])]))) 


The  assumption  { =  (LEAOER)  ME)  from  the  plan  for  ( FLUSH  QS )  is  plugged  in  using  a  general 
rule  for  propagating  equalities: 

RULE354:  (and ...  [=  e  c] ...  [...  e ...] ...)  ->  (and ...  [=  e  c] ...  [...  c ...} ...) 


The  clause  [  =  (SUIT-OF  (CARD-OF  ME))  (SUIT-OF  (CARD-OF  ME) )]  is  eliminated.  The 

quantified  sub-expression  is  reduced  to  the  sufficient  condition  [HIGHER  QS  (CARD-OF  ME)]  based 

on  die  assumption  that  QS  will  be  in  the  suit  led.  This  condition  on  (CARD-OF  ME)  is  then  used  to 

constrain  the  action  (LEAD-SPADE  ME): 

5:32-49  ---  [by  RULE354.  analysis]  — > 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE 

(AND  [=*  (LEADER)  ME] 

[SPAOE1  (CARD-OF  ME)] 

[HIGHER  QS  (CARD-OF  ME)]))) 

5:52-53  -—  [RECOGNIZE  by  RULE123]  — > 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE  (LEAD-SAFE-SPADE  ME))) 


Part  of  the  derivation  is  a  proof  that  underplaying  the  Queen  is  sufficient  to  avoid  taking  it, 

specifically,  that  the  Queen  will  be  in  the  suit  led  if  it’s  played: 

5:40-45 

(IN  QS  (CARDS-PLAYED-IN-SUIT-LED)) 

—  [by  analysis]  — > 

(AND'[IN  QS  (CARDS-PLAYED)] 

[=  S  (SUIT-LED)]) 

5:42 

(IN  QS  (CARDS-PLAYED)) 

---  [REDUCE  by  RULE301 ]  — > 

T 

5:46-47 

(=  S  (SUIT-LED)) 

— -  [REDUCE  by  RULE301]  — > 

(»  S  S) 

5:48 

—  [EVAL  by  RULE179]  ---> 

(SHOW  T) 
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The  proof  takes  as  premises  that  player  ME  will  lead  a  spade  and  the  Queen  will  be  played  in  the 
trick.  These  premises  are  represented  as  follows: 

{*  (LEADER)  ME) 

(SPADE!  (CARD-OF  ME)) 

(IN  QS  (CARDS-PLAYEO)) 


The  proof  shown  contains  a  gap  represented  by  the  use  of  RULE301  at  5 : 46-47,  where  the  suit 
led  is  determined  to  be  spades.  It  could  be  filled  in  by  expanding  the  definition  of  “suit  led,” 
propagating  the  first  premise  using  RULE354  as  before,  reformulating  the  second  premise  as  an 
equality,  and  propagating  it: 


(SUIT-LED) 

---  [ELABORATE  by  RULE124]  -— > 
(SUIT-OF  (LEADER)) 

—  [by  RULE354]  ---> 

(SUIT-OF  (CARD-OF  ME)) 

(SPAOE !  (CARD-OF  ME)) 

---  [ELABORATE  by  RULE124]  — -> 

(-  (SUIT-OF  (CARD-OF  ME))  S) 

(SUIT-OF  (CARD-OF  ME)) 

---  [by  RULE354]  -  — > 

S 


2.10.3.  Propagating  Equalities 

One  theme  apparent  in  this  example  is  that  reformulating  constraints  as  equalities  is  a  good  idea, 
since  they  can  readily  be  propagated  in  that  form.  FOO’s  transformational  flavor  makes  such 
propagation  a  bit  unwieldy,  since  inferences  arc  generally  made  by  transforming  a  single  monolithic 
"current  expression"  rather  than  operating  freely  on  a  set  of  premises. 

A  more  sophisticated  problem-solving  apparatus  might  maintain  equivalence  classes  of  expressions 
known  to  be  equal  [Nelson  79).  In  this  approach,  the  premises  { =  (LEADER)  ME)  and 
(=  (SUIT-OF  (CARD-OF  ME))  S)  would  be  represented  in  the  graph  structure  shown  in  Figure  2- 
2.  Each  list  expression  and  atom  in  the  figure  denotes  a  node  in  the  graph.  Fjch  list  expression  is 
connected  by  an  ordered  list  of  arcs  to  the  nodes  representing  its  components,  as  denoted  by  the 
diagonal  and  horizontal  lines  in  the  figure.  Expressions  known  to  be  equal  arc  marked  as  belonging 
to  the  same  equivalence  class,  as  denoted  by  vertical  lines  from  (SUIT-LED)  to  its  definition 
(SUIT-OF  (CARD-OF  (LEADER)),  from  (LEADER)  to  ME,  and  from  (SUIT-OF  (CARD-OF  ME))  to 
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(SUIT-LED) 

|\ 

*  \  — -  SUIT-LED 

I 

(SUIT-OF  (CARO-OF  (LEADER))) 
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\---  SUIT-OF 
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(SUIT-OF  (CARD-OF  ME)) 
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I  \—  (CARD-OF  ME) 
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S 


Figure  2-2:  Graph  Representation  for  Equality  Propagation 


The  algorithm  for  propagating  equalities  puts  two  expressions  in  the  same  equivalence  class  if  their 
corresponding  components  are  equal.  Thus  (CARD-OF  ME)  and  (CARD-OF  (LEADER))  would  get 
marked  equal  since  their  first  components  arc  the  same  atom  and  their  second  components  are  in  the 
same  equivalence  class.  Then  (SUIT-OF  (CARD-OF  (LEADER))  and  (SUIT-OF  (CARD-OF  ME)) 
would  get  marked  equal  for  the  same  reason.  The  algorithm  would  automatically  mark  (SUIT-LED) 
equal  to  S.  since  it  merges  two  equivalence  classes  whenever  a  member  of  one  is  marked  equal  to  a 
member  of  the  other. 

Also,  if  two  equal  expressions  have  the  same  first  componcnL  i-e„  are  both  of  the  form  (f ...)  for 
some  function  f,  and  if  f  is  known  to  be  injective  (one-to-one),  the  algorithm  marks  tire  corresponding 
components  of  the  expressions  equal.  [Nelson  79J  uses  this  method  to  deduce  that  if  two  CONS  cells 
are  equal,  their  respective  CARs  and  CDRs  are  equal.  This  feature  is  not  illustrated  in  the  example 
above,  but  could  be  used,  say,  to  deduce  p  =  q  from  (CARD-OF  p)  =  (CARD-OF  q)  since  CARD-OF  is 
an  injective  function,  i.e.,  a  player  only  plays  one  card  per  trick. 
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2.10.4.  Integrating  Multiple  Goals:  Summary 

When  multiple  goals  interact,  solving  them  independently  may  lead  to  inconsistencies. 

Approaches  for  constructing  plans  to  achieve  multiple  goals  include:  * 

Record  the  assumptions  made  in  solving  one  goal  and  apply  them  to  the  others. 

Construct  a  plan  to  achieve  one  goal  and  modify  it  to  achieve  the  other. 

* 

Representing  assumptions  as  equalities  of  the  form  <cxpression>  =  <valuc>  makes  it  easy  to 
retrieve  and  apply  them  by  substituting  <value>  for  instances  of  <expression>  elsewhere  in  the 
problem.  Such  a  representation  would  permit  application  of  an  existing  graph-based  inference 
technique  for  efficient  propagation  of  equalities.  % 


2.11.  Temporal  Goals 

An  interesting  issue  in  operationalization  is  how  methods  expressed  in  one  paradigm  can  be  * 

brought  to  bear  on  a  problem  stated  in  another.  For  example,  planning  methods  can  be  applied  to 
the  problem  of  making  a  sequence  generator  satisfy  a  specified  constraint,  by  means  of  the  following 
strategy: 

1.  Reformulate  the  constraint  as  a  goal,  with  partial  sequences  as  states,  and  sequence  extension  as 
the  only  action. 

2.  Solve  the  goal  using  planning  rules. 

3.  Reformulate  the  constructed  plan  as  a  constraint  on  a  leff-to-right  sequence  generator  that 

depends  only  on  elements  already  generated.  * 

2,11.1.  Example:  Satisfy  Unique-Climax  Constraint 

* 

DERIV14  uses  this  strategy  to  apply  rules  about  achieving  goals  over  time  to  the  task  of 
constructing  a  tone  sequence  (cantus  firmus)  satisfying  various  constraints.  The  constraint  treated  in 
DERIV14  is: 

C4.  The  climax  (highest  note)  of  the  cantus  must  occur  exactly  once. 

This  constraint  is  encoded  as  the  expression 


(*  (^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  I) 


t 
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Here  CANTUS  is  a  variable  denoting  the  sequence  to  be  constructed.  The  same  constraint  is 
incorporated  in  a  heuristic  search  in  DERIV13  (§3.5.3.4)  by  choosing  the  climax  a  priori  (§2.12.1).  In 
I  DERIV14,  however,  rules  about  goals  are  used  to  satisfy  the  constraint  without  determining  the 

climax  beforehand,  by  devising  an  obvious  (to  humans)  strategy  for  choosing  the  next  note: 

If  the  highest  tone  so  far  occurs  only  once,  choose  a  lower  tone  to  keep  it  that  way:  otherwise 
choose  a  higher  tone  to  be  the  new  (uniquely-occurring)  climax. 

DERIV14  begins  by  parameterizing  the  problem  over  “time,”  where  each  successive  note 
corresponds  to  one  time  unit: 

(ACHIEVE  (=  {^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  I)) 

14:1-4  ---  [by  RULE266]  ---> 

(FORALL  T 1  (LB :UB  0  (-  (#  CANTUS)  1)) 

([ACHIEVE  (=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)]  Tl)) 

HereCANTUS-1  =  (LAMBDA  (I)  (PREFIX  CANTUS  I))  denotes  the  subsequence  of  the  cantus 
determined  “so  far,”  Le.,  at  time  I,  and  acts  as  a  fluent  (time-dependent  quantity)  inside  the 
bracketed  sub-expression.  The  overall  expression  says  that  the  goal  at  each  time  T  l  is  for  the  highest 
note  so  far  in  the  cantus  to  occur  only  once.  Since  this  goal  refers  to  the  action  to  be  taken  at  time  T  l 
--  extending  the  cantus  by  the  next  note  -  Tl  ranges  from  zero  up  to  one  less  than  the  length  of  the 
cantus.  The  expression  specifies  that  this  goal  is  to  be  achieved  at  every  Tl  in  this  range.  This 
condition  is  unnecessarily  strong,  since  all  that  matters  is  for  the  goal  to  be  satisfied  for  the  last  value 
of  Tl.  Representing  the  correct  condition  would  require  something  like  the  idea  of  a  deadline  for 
achieving  a  goal.  However,  the  interesting  aspects  of  the  derivation  concern  the  goal  itself,  rather 
than  die  priority  assigned  to  achieving  it  at  any  given  time. 

The  idea  of  treating  a  sequence  constraint  as  a  temporal  goal  is  implemented  as 

RULE266:  (achieve  Ps)  ->  (forall  t  (lb:ub  0  (-  (#  s)  1))  ([achieve  Ps']  t)), 
where  s  is  a  sequence  to  be  constucted,  and  s'  =  (lambda  (t)  (prefix  s  t)) 

Achieving  a  temporal  goal  P  is  defined  as  making  it  true  at  time  t+ 1.  The  functional  NEXT  takes  a 
fluent  -  implicit  function  of  t  --  and  returns  its  next  value,  ue.,  the  same  implicit  function  applied  to 
t+ 1.  This  provides  the  rationale  for 

RULE282:  (achieve  P)  ->  (next  P) 

That  is,  P  is  achieved  at  time  t  if  P  is  true  at  time  t+ 1.  The  modal  operator  NEXT  commutes  freely 


with  other  functions: 
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(next  (f  c))  =  (f  (next  e))  if  e  is  a  fluent  (implicit  function  of  time) 


Of  course 

(next  (f  e))  =  (f  e)  if  e  is  time-independent 


These  two  properties  are  combined  in 

RULE283:  (next  (f et ...  en))  ->  (f e^ ...  en'), 

where  ef  =  (next  e4)  if  e;  is  a  fluent,  and  e.’  =  Cj  otherwise 


As  implemented,  RULE283  assumes  that  any  expression  containing  an  unapplied  function  is  a 
fluent.  A  more  accurate  method  for  mechanical  identification  of  fluents  would  require  marking 
primitive  (undefined)  concepts  of  the  domain,  like  the  LOC  function,  as  fluents.  An  expression  might 
then  be  identified  as  fluent  or  time-independent  by  expanding  it  in  terms  of  primitive  concepts  and 
looking  for  unapplied  fluents. 


RULE282  and  RULE283  justify  the  transformation 

(ACHIEVE  (*  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)) 
14:5-7  ---  [by  RULEZ8Z,  RULEZ83]  ---> 

(  =  {^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1))  (NEXT  CANTUS-1))  1) 


This  expression  specifies  that  extending  the  current  partial  sequence  CANTUS-1  should  yield  a 
sequence  with  a  unique  climax.  Further  analysis  depends  on  whether  the  climax  changes  in  the 
process.  This  distinction  is  expressed  by 

RULF.276:  (P...  (next  c)  ...)-> 

(or  (and  [not  (change  e))  [P  ...  c ...]]  [and  [change  e]  [P ...  (next  c) ...]]) 

Split  a  predicate  on  a  fluent  into  two  cases  depending  on  whether  the  fluent  changes. 


RULE276  is  applied  with  e  =  (CLIMAX  CANTUS-1): 

(=  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1))  (NEXT  CANTUS-1))  1) 
14:3  ---  [DISTRIBUTE  by  RULEZ76]  — > 

(OR  [AND  [NOT  (CHANGE  (CLIMAX  CANTUS-1))] 

[=  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  (NEXT  CANTUS-1))  1]] 
[AND  [CHANGE  (CLIMAX  CANTUS-1)] 

[=  ( ^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1)) 

(NEXT  CANTUS-1)) 

1]3) 


The  first  case,  where  the  climax  doesn't  change,  is: 


m 
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(AND  [NOT  (CHANGE  (CLIMAX  CANTUS- 1))] 

[=  (OCCURRENCES  (CLIMAX  CANTUS-1)  (NEXT  CANTUS-1))  1]) 


The  object  is  to  reduce  it  to  a  condition  on  the  next  note  to  be  chosen.  This  requires  the 
transformation 

(NEXT  CANTUS-1) 

14:10-17  —  [by  analysis]  — > 

(APPEND  CANTUS-1  (LIST  (NEXT  NOTE))) 


This  transformation  falls  out  quite  neatly  from  the  definition  of  the  functional 

NEXT  =  (LAMBDA  (F) 

(LAMBDA  (I)  (F  (+  I  1)))) 


It  requires  the  segmentation  of  s1 ...  si+ 1  into  s^ ...  s(  followed  by  s.  j,  effected  by 
RULE274:  (prefix  s  (+  i  1))  ->  (append  (prefix  s  i)  (list  (nth  s  (+i  1)))) 


Finally,  functions  arc  freely  treated  as  functionals,  as  expressed  by 

RULE393:  (lambda  (t)  (f  ex ...  en))  ->  (f  (lambda  (t)  e^ ...  (lambda  (t)  en)) 


The  rest  of  the  analysis  of  the  first  case  is  fairly  straightforward: 

(=  (OCCURRENCES  (CLIMAX  CANTUS-1) 

(APPEND  CANTUS-1  (LIST  (NEXT  NOTE)))) 

1) 

14:18  ---  [DISTRIBUTE  by  RULE284]  — > 

(=  (+  (OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

(OCCURRENCES  (CLIMAX  CANTUS-1)  (LIST  (NEXT  NOTE)))) 

1) 


The  second  term  of  the  sum  is  1  if  the  next  note  repeats  the  climax,  0  otherwise,  so  the  first  term 
must  be  0  or  1: 

14:19-27  —  [by  analysis]  — > 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(=  (OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0) 

(=  (OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)) 


It  can't  be  0,  since  (CLIMAX  CANTUS-1)  is  by  definition  an  clement  of  CANTUS- 1.  So  it  must  be  1, 

and  the  next  note  can’t  repeat  the  climax: 

14:28-36  —  [by  casa  elimination]  — > 

(AND  [=  (OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]) 
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Nor  can  the  next  note  be  higher  than  the  climax: 

(NOT  (CHANGE  (CLIMAX  CANTUS-1))) 

14:40-45  —  [BY  RULE277 ,  analysis]  — - > 

(NOT  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))) 

The  rationale  for  this  step  is  a  general  principle: 

The  extremum  of  an  expanding  set  changes  iff  one  of  the  new  elements  lies  beyond  it. 

This  is  expressed  by 

RULE277:  (change  (MaxR  s))  ->  (R  (MaxR  (change  s))  (MaxR  s))  if  s  is  expanding, 
where  (MaxR  s)  is  the  maximal  element  of  s  with  respect  to  the  ordering  R 

2.11.1.1  Representational  Ambiguity  and  Conciseness 

The  construct  (change  e)  is  used  ambiguously  to  mean  both  Ae  and  Ae  *  0.  Thus  (change  s) 
denotes  the  new  elements  of  the  expanded  set  or  sequence  s',  while  (change  (MaxR  s))  denotes  the 
proposition  that  the  maximum  changes,  Le.,  that  (MaxR  s)  *  (MaxR  s’).  Such  ambiguity  is 
representationally  sloppy  but  concise.  In  that  respect  it  resembles  the  practice  of  quantifying  over 
sequences  as  though  they  were  sets.  The  danger  of  this  practice  is  illustrated  by  representing  the 
number  of  occurrences  of  C  in  the  sequence  S  as 
(#  (SET-OF  X  S  (=  X  C) ) ) 

The  value  of  this  expression  should  always  be  cither  0  or  l.  A  precise  but  longer  notation  for 
number  of  occurrences  of  C  in  a  sequence  S  is 

(i ¥  (SET-OF  X  S  (=  (VALUE-OF  X)  C))) 

Here  a  sequence  S  =  x^ ...  xn  is  represented  as  a  set  of  pairs  <i,  x;>,  and  (valuc-of  <i,  x(>)  =  Xj. 

Anyway,  the  case  in  which  the  climax  doesn’t  change  reduces  to 

(AND  [=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))] 

[NOT  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]) 

14:47-50  —  [by  analysis]  — > 

(AND  [=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

The  case  in  which  the  climax  docs  change  is 
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(AND  [CHANGE  (CLIMAX  CANTUS- 1)] 

[*  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1))  (NEXT  CANTUS-1)) 

1]) 


The  climax  changes  iff  the  new  note  is  higher  than  the  existing  climax: 

14:52-60  —  [by  analysis]  — > 

(AND  [HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1)] 

[«  (^OCCURRENCES  (NEXT  NOTE)  (NEXT  CANTUS-1))  1]) 


As  in  the  first  case,  the  expression  (^OCCURRENCES  . . . )  is  split  into  two  terms: 

14:62-68  —  [by  analysis]  — > 

(AND  [HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1)] 

[*  (+  (^OCCURRENCES  (NEXT  NOTE)  CANTUS-1)  1)  lj) 

14:69  ---  [by  RULE290]  — > 

(AND  [HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1)] 

[=■  (^OCCURRENCES  (NEXT  NOTE)  CANTUS-1)  0]) 


The  second  conjunct  is  subsumed  by  the  first: 

(=  (^OCCURRENCES  (NEXT  NOTE)  CANTUS-1)  0) 

14:70-72  -  [by  analysis]  - > 

(NOT  (IN  (NEXT  NOTE)  CANTUS-1)) 

14:73-77  -—  [by  RULE3Q4 ,  analysis]  — -> 

T 


The  idea  here  is  that 

An  entity  that  lies  beyond  an  extreme  element  of a  set  can  7  be  a  member  of  it. 

This  idea  is  expressed  by 

RULE304:  (in  x  s)  ->  nil  if  (R  x  (MaxR  s))  for  some  ordering  R  on  s 
In  this  case,  x  =  (NEXT  NOTE),s  =  CANTUS- 1,  R  =  HIGHER,  and  MaxR  =  HIGHEST. 

Thus  the  two  cases  reduce  to 

(OR  [AND  [=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]] 

[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

The  derivation  ends  by  translating  this  expression,  which  contains  the  fluent  CANTUS-l,  back  into 
a  stauc  sequence  constraint.  This  is  accomplished  by  plugging  in  the  quantifier  variable  T  l  to  which 
the  expression  is  functionally  applied: 
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(FORALL  T 1  (LB  :UB  0  (-  (*  CANTUS)  1)) 

([OR  [AND  [  =  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]] 

[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]] 

TD) 

14:82-87  —  [by  RULE273 ,  analysis]  — > 

(FORALL  T 1  (L8:U8  0  (-  (#  CANTUS)  1)) 

(OR  [AND  [*  (^OCCURRENCES  (CLIMAX  (CANTUS-1  T1 ) )  (CANTUS-1  T 1 ) ) 
1] 

[LOWER  (NOTE  (+  T1  1))  (CLIMAX  (CANTUS-1  T1 ) )]] 

[HIGHER  (NOTE  (+  T1  1))  (CLIMAX  (CANTUS-1  T1 )  ) ] ) ) 


This  transformation  is  performed  by 

RULE273:  ([f ...  gL ...  gn  ...]  t)  ->  (f ...  (gt  t) ...  (gn  t) ...),  where  are  fluents 


The  resulting  expression  could  be  used  to  constrain  a  lcft-to-right  tone  sequence  generator,  since 
the  quantified  condition  on  (NOTE  (+  Ti  l ) )  depends  only  on  (CANTUS-1  Tl),  defined  as 
(PREFIX  CANTUS  Tl). 


2.11.2.  Temporal  Goals:  Summary 

A  general  strategy  for  applying  a  method  to  a  problem  is: 

1.  Translate  the  problem  into  the  language  of  the  method. 

2.  Solve  the  translated  problem  using  the  method. 

3.  Translate  die  solution  back  into  the  original  language  of  the  problem,  if  necessary. 

In  particular,  planning  metliods  can  be  applied  to  sequence  constraints: 

1.  Translate  the  sequence  constraint  into  a  temporal  goal. 

2.  Solve  the  temporal  goal  using  planning  methods. 

3.  Translate  the  plan  back  into  an  operational  constraint  on  a  lcft-to-right  sequence  generator. 

(n  the  example  treated  in  the  section,  the  planning  methods  split  goals  into  different  cases  and 
simplify  them  based  on  general  knowledge  about  extrema  of  sets  and  change  over  time. 
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2.12.  Parameterization 

An  operationalization  method  may  reduce  a  problem  rather  than  solve  it  outright.  One  such  is: 
Assume  the  value  of  some  problem  feature  is  determined  a  priori. 

This  value  might  be  any  of  several  tilings: 

1.  A  design  parameter  chosen  as  part  of  the  operationalization  process. 

2.  An  input  variable  in  a  parameterized  solution. 

3.  A  quantity  known  at  the  dme  the  solution  is  used  but  not  at  the  time  the  problem  is  solved. 

As  it  happens,  all  the  illustrations  of  this  technique  drawn  from  the  derivations  occur  in  the  context 
of  applying  the  heuristic  search  method  and  arc  described  in  more  detail  in  the  discussion  of  that 
method  (§3.5).  However,  the  ideas  involved  can  be  discussed  independently  of  the  details  of  heuristic 
search. 

2.12.1.  Parameterizing  a  Problem 

The  problem  of  satisfying  a  constraint  on  some  feature  of  a  constructed  object  can  often  be 
simplified  by  first  deciding  the  value  of  that  feature.  For  example,  consider  die  problem  of 
constructing  a  cantus  (sequence  of  musical  tones)  satisfying  the  constraint 

C4.  The  climax  tone  of  the  cantus  must  occur  exactly  once. 

This  problem  can  be  simplified  by  choosing  the  climax  tone  a  priori .  and  then  using  it  exactly  once 
in  the  cantus,  rather  than  determining  the  climax  dynamically  as  the  cantus  is  generated,  as  in 
DERIV14  (§2.11). 

The  moral  of  this  example  is,  'To  simplify  a  problem,  parameterize  it."  More  precisely, 

To  constrain  a  constructed  object  to  satisfy  a  specified  property,  first  choose  the  value  of  some 
parameter  on  which  the  property  depends  and  then  construct  the  object  so  as  to  ensure  that  ( a)  the 
parameter  takes  on  the  chosen  value,  and  (b)  the  property  is  satisfied Jbr  that  value. 

Ideally,  it  should  be  possible  to  satisfy  (a)  and  (b)  by  constraining  the  construction  process  in  a  way 
that  at  each  point  depends  only  on  the  part  constructed  so  far.  This  property  is  important  in  heuristic 
search  (§3),  where  the  search  space  is  pruaed  by  applying  constraints  to  incomplete  paths. 
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2.12.1.1  Parameterizing  the  Cantus  Climax 


The  strategy  of  reducing  a  problem  by  parameterizing  it  is  illustrated  in  the  following  step  from 

DERIVD  (shown  here  with  some  cosmetic  changes  for  compatibility  with  DERIV'D): 

(ACHIEVE  (=  (^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  1)) 

13:58  ---  [RESTRICT  by  RULE256]  ---> 

(ACHIEVE  (AND  [*  (CLIMAX  CANTUS)  CLIMAX1] 

[  =  (^OCCURRENCES  CLIMAX1  CANTUS)  1])) 

(ASSUME  (SELECT  CLIMAX1  (TONES))) 


This  transformation  is  suggested  by 

RULF.256:  (P  ...  (fs)  ...)->  (and  [=  (f  s)  c]  [P  ...c  ...j), 
where  c  is  to  be  selected  from  (range  0  before  s  is  constructed 

The  first  conjunct  constrains  the  climax  of  the  cantus  to  be  the  pre-selected  tone: 

(*  (CLIMAX  CANTUS)  CLIMAX1) 

13:60-62  —  [by  analysis]  — > 

(AND  [IN  CLIMAX1  CANTUS] 

[FORALL  XI  CANTUS  (NOT  (HIGHER  XI  CLIMAX1))]) 


Thus  the  cantus  must  contain  the  pre-selected  tone  and  no  higher  tones. 


The  second  conjunct  constrains  the  pre-selected  tone  to  occur  exactly  once  in  the  cantus: 

(=  (^OCCURRENCES  CLIMAX1  CANTUS)  1) 

13:83  ---  [ELA80RATE  by  RULE340]  ---> 

(AND  [>=  (^OCCURRENCES  CLIMAX1  CANTUS)  1] 

[=<  (^OCCURRENCES  CLIMAX1  CANTUS)  1]) 

13:84-116  ---  [by  analysis]  ---> 

(AND  [IN  CLIMAX1  CANTUS] 

[FORALL  II  (LB:UB  0  (-  (#  CANTUS)  1)) 

(OR  [NOT  (=  (NOTE  (+  II  1))  CLIMAX1)] 

[NOT  (IN  CLIMAX  1  (PREFIX  CANTUS  II))])]) 


That  is,  the  pre-selected  tone  must  be  used  at  some  point  in  the  generation  of  the  cantus,  but 
cannot  be  used  thereafter.  The  reformulated  conjuncts  can  be  used  to  constrain  a  left-to-right  tone 
sequence  generator,  since  they  depend  only  on  the  notes  generated  so  far  at  each  point.  The 
constraint  (IN  CLIMAX1  CANTUS)  is  satisfied  as  soon  as  the  pre-selected  tone  is  generated;  this  is 
explained  more  precisely  in  the  discussion  of  heuristic  search  (§3.5.5.3). 
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2.12.1.2  Parameterizing  the  Cantus  Length 

The  same  rule  for  parameterization  could  also  be  used  to  simplify  another  constraint: 

Cl.  The  cantus  should  be  between  8  and  16  notes  long. 

RULE256  suggests  choosing  the  cantus  length  a  priori: 

(ACHIEVE  (IN  (if  CANTUS)  ( LB :  UB  8  16))) 

---  [RESTRICT  by  RULE256 .  analysis]  ---> 

(ACHIEVE  (=  (#  CANTUS)  LENGTH1 ) ) 

(ASSUME  (SELECT  LENGTH1  (L8:U8  3  16))) 

This  expression  could  be  used  to  produce  a  left-to-right  generator  of  the  form 
Select  LENGTH1  from  (LB-.U8  8  16 )-- at  random  or  by  asking  user 
For  II  from  1  to  LENGTH1  generate  (NOTE  II) 

It's  interesting  to  note  that  Meehan's  cantus  generation  program  [Meehan  72[  has  this  form. 

2.12.1.3  Parameterizing  the  Cantus  Range 

The  same  rule  could  be  used  to  simplify  die  constraint 

C3.  The  melodic  range  of  the  cantus  should  not  exceed  a  major  tenth. 


Here.  RLI  1 '256  suggests  choosing  the  lowest  and  highest  notes  a  priori : 

(ACHIEVE  (=<  (MELODIC-RANGE  CANTUS)  (MAJOR  10))) 

---  [ELABORATE  by  RULE  124]  ---> 

(ACHIEVE  (-<  (SIZE  ^INTERVAL  (LOWEST  CANTUS)  (HIGHEST  CANTUS))) 
(MAJOR  10))) 

---  [RESTRICT  by  RULE258]  ---> 

(ACHIEVE  (AND  [*<  (SIZE  (INTERVAL  L0WEST1  HIGHEST  1 )  )  (MAJOR  10)] 
[*  (LOWEST  CANTUS)  LOWEST  1] 

[*  (HIGHEST  CANTUS)  HIGHEST  1  ] ) 

(ASSUME  (SELECT  L0WEST1  (TONES))) 

(ASSUME  (SELECT  HIGHEST  1  (TONES))) 

---  [by  analysis]  -  —  > 

(ACHIEVE  'ANO  [*<  (SIZE  (INTERVAL  L0WEST1  HIGHEST  1 ) )  (MAJOR  10)] 
[IN  LOWEST  1  CANTUS] 

[IN  HIGHEST  I  CANTUS ] 

[FORALL  II  (LB:UB  1  [tf  CANTUS)) 

(ANO  [NOT  (LOWER  (NOTE  II)  L0WEST1)] 

[NOT  (HIGHER  (NOTE  II)  HIGHEST  l ) ] ) ] ) ) 
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The  first  conjunct  constrains  the  choice  of  LOWEST t  and  HIGHEST  1,  and  can  be  satisfied  by 
choosing  them  appropriately  (§2.7.1).  1'he  last  conjunct  constrains  the  choice  of  eieh  note 
independent  of  the  other  notes,  and  can  therefore  be  incorporated  in  a  lett-to-right  generator.  This 

» 

solution  resembles  Meehan's  program,  which  asks  the  user  to  specify  a  climax  tone  (used  as  the 
highest  note  of  the  cantus)  and  a  lowest  permissible  tone  (not  always  included  in  die  cantus).  The 
second  and  diird  conjuncts  constrain  the  actual  melodic  range  of  the  cantus  to  cover  die  full  interval 
between  die  pre-selected  tones,  and  are  not  required  by  die  original  constraint  that  the  range  be  less 
dun  a  major  tenth.  A  derivation  of  a  more  sophisticated  solution  omitting  these  unnecessary 
constraints  is  sketched  later  (§3. 5. 5. 5). 

2.12.2.  Parameterizing  the  Solution 

Sometimes  a  problem  can  be  simplified  a  good  deal  just  by  assuming  that  some  piece  of 
information  will  be  known  at  die  time  die  solution  is  used.  This  idea  is  illustrated  in  D1-RIY2.  where 
"avoid  taking  points"  is  operationalized  as  a  heuristic  search  (§3).  The  search  space  consists  of  die 
possible  scenarios  (card  sequences)  for  die  trick;  die  purpose  of  the  search  is  to  determine  whether 
any  of  diese  scenarios  cause  player  ME  to  take  points.  The  search  can  be  simplified  considerably  by 
assuming  diat  the  suit  led.  the  cards  played  by  player  he's  predecessors,  and  the  card  player  me  is 
considering  playing  are  all  known  before  the  search  starts.  The  details  of  the  assumption  process  arc 
giver,  later  (§3.4.2).  The  general  idea  underlying  it  is 

To  simplify  a  problem,  parameterize  the  solution. 

More  precisely; 

To  evaluate  a  property  Py.  c)  of  some  object  e.  chouse  some  feature  (f  c)  on  winch  the  property 
depends,  make  it  a  variable  v.  and  express  the  property  as  an  evaluable  function  P  . 

If  the  value  of  die  feature  (f  c)  is  known  at  evaluation  time,  it  can  be  assigned  to  die  variable  v 
before  the  expression  is  evaluated;  otherwise,  die  expression  P  can  be  treated  as  a  function. 

An  example  of  a  feature  known  at  evaluation  time  is  the  card  sequence  played  by  player  MB's  $ 

predecessors  (assuming  dial  the  search  is  performed  as  part  of  die  process  whereby  player  me  chooses 
a  card  to  play). 


« 


i 


An  example  of  a  feature  not  determined  at  evaluation  time  is  the  card  to  be  played  by  player  me.  If 
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this  is  mode  a  variable,  player  ME  can  evaluate  each  card  it’s  considering  playing  by  executing  the 
search  procedure  with  mat  card  as  die  value  of  die  variable. 

An  example  of  a  feature  somc'imcs  but  not  always  determined  at  evaluation  time  is  the  suit  led.  If 
player  ME  is  leading,  the  suit  led  is  unknown,  and  player  ME  can  execute  different  searches  with 
different  values  for  the  "suit  led"  variable  corresponding  to  the  respective  suits  of  the  different  cards 
it's  considering  leading.  If  someone  else  is  leading,  the  suit  led  will  be  known  at  the  dmc  of  player 
ME’s  turn,  and  can  be  assigned  to  the  “suit  led”  variable  before  the  search  begins. 

2.12.3.  Parameterization:  Summary 

Parameterization  reduces  a  problem  P  f  to  a  simpler  problem  Pv.  There  arc  several  cases: 

1. Thc  value  of  (f  ...)  will  be  known  or  chosen  at  evaluation  time  and  can  be  assigned  to  the 
variable  v. 

2.  Py  will  be  evaluated  for  different  values  of  (f 

3.  The  problem  of  ensuring  (f ...)  =  v  is  treated  as  an  additional  goal. 

This  simple  strategy  accounts  for  several  design  decisions  in  Meehan's  cantus  generating  program. 

2.13.  Operationalization  Mthods:  Summary 

The  term  "operationalization”  refers  to  die  process  of  making  an  expression  operational.  i.e„ 
"opcrational-ization."  The  alternative  segmentation  "opcration-alization”  suggests  another 
definition:  reformulating  an  expression  in  terms  of  a  given  set  of  executable  operations.  This  v  icw  is 
based  on  the  task  agent  model  shown  in  Figure  1-1  (§1.1.1).  In  this  model,  an  expression  can  be  non- 
operationa!  for  any  of  several  reasons.  An  expression  to  be  evaluated  might  be  defined  in  terms  of 
unobservable  data,  or  depend  on  ail  unpredictable  future  event.  Similarly,  a  goal  to  be  achieved  might 
not  be  expressed  as  a  doable  action,  or  it  might  depend  on  an  uncontrollable  choice  made  by  some 
other  agent. 

Hach  operationalization  method  presented  in  this  chapter  can  be  characterized  as  overcoming  a 
particular  kind  of  obstacle  to  operationally: 

1.  The  pigeon-hole  method  reformulates  a  function  of  unobservable  data  in  terms  of  known 
data  (§2.2). 

^Contrary  :o  some  colleagues  suggestions,  "opcraltonali.’aiion"  Joes  no<  mean  rationalizing  -  or  nationalizing  -  opera. 
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2.  The  disjoint  subsets  method  estimates  a  function  of  unobservable  data  based  on  known 
data  (§2.3). 

3.  Historical  reasoning  computes  a  function  of  unobservable  data  based  on  remembered  data  ( §2.4). 

4.  The  set  depletion  method  helps  translate  a  non-operational  goal  into  a  series  of  doable 
actions!  §2.5). 

5.  Finding  a  necessary  or  sufficient  condition  (§2.6)  helps: 

Evaluate  (in  some  situations)  a  function  of  unobservable  data  based  on  known 
data  (§2.6.2)  (§2.6.3). 

Reformulate  a  non-openuional  goal  into  a  doable  action  that  achieves  a  sufficient 
condition  (§2.6). 

6. 1'OO’s  model  of  choice  (§2.7)  is  used  in  both  planning  and  evaluation: 

Constrained  choice  reformulates  a  goal  involving  an  unpredictable  choice  as  a  doable 
plan  (§2.7.1). 

Forcing  helps  translate  a  goal  involving  an  uncontrollable  choice  into  a  doable 
plan  (§2.7.2). 

Pessimism  estimates  a  function  of  an  unpredictable  choice  based  on  known  dam  (§2.7.3). 

7.  Dependence  analysis  estimates  a  function  of  unobservable  data  based  on  known  dan  (§2.3). 

S.  Simplifying  assumptions  (§2.9)  help: 

Create  a  doable  plan  to  achieve  a  goal  involving  an  unpredictable  condition  (§2.9.2). 
Estimate  a  function  of  unobservable  data  based  on  an  untested  assumption  (§2.9.3). 

9.  Integrating  multiple  goals  helps  translate  a  non-operational  conjunction  into  a  doable 
plan  (§2.10). 

10.  Temporal  planning  helps  translate  a  goal  involving  an  unpredictable  sequence  into  a  doable 
plan  (§2.11). 

11.  Parameterization  makes  an  unpredictable  quantity  into  a  choice  v  ariable  (§2.12). 

12.  Choice  set  ordering  reformulates  a  non-operational  goal  in  terms  of  a  controllable 
choice  (§2.8.3). 

13.  Heuristic  search  evaluates  a  function  of  unpredictable  data  by  considering  alternative 
possibilities  (§3). 

14.  Reformulation  (§4)  helps: 

Evaluate  a  function  of  unobservable data  based  on  observable  data  (§4. 3. 1.1). 

Translate  a  non-operational  goal  into  a  controllable  choice  (§4.3. 1.2). 

Translate  a  non-operational  goal  into  a  doable  action  (§4. 3. 1.3). 

The  last  items  on  this  list  refer  to  methods  not  yet  discussed  in  detail.  Reformulation  sometimes 
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suffices  to  solve  an  operationalization  problem,  but  more  often  serves  to  enable  the  application  of  one 
of  die  operationalization  methods  described  in  this  chapter.  This  crucial  process  is  discussed  in  (§4). 

Heuristic  search  (§3)  docs  not  (it  the  simplistic  mode!  of  agent-environmeni  interaction  depicted  in 
Figure  1-1.  For  example,  this  model  ignores  computational  costs,  which  are  a  central  factor 
motivating  the  search  refinement  nilcs  discussed  in  (§3.4).  Also,  heuristic  search  is  a  complex  process 
internal  to  the  agent,  but  the  model  focuses  on  interactions  with  the  external  environment.  Heuristic 
search  can  be  embedded  in  the  model  to  some  extent  by  treating  it  as  an  external  process  occurring 
over  time:  for  example,  die  complete  solution  path  can  be  treated  as  "unpredictable”  data,  and 
desired  properties  of  a  solution  can  be  reformulated  as  tests  on  "observable"  partial  paths  or 
"controllable"  individual  choice  points.  However,  this  view  fails  to  represent  die  way  such  tests 
(internally  computed  functions)  are  used  in  the  search  (external  environmental  process). 

Another  consequence  of  die  complexity  of  heuristic  search  relative  to  the  rather  simple  methods 
discussed  so  far  is  the  complexity  of  the  process  whereby  a  problem  is  reformulated  as  a  heuristic 
search  problem.  This  process  is  a  fundamental  activity  in  the  practice  of  AI  or  "knowledge 
engineering."  and  serves  as  the  focus  of  the  next  chapter. 


§3.  Using  die  Heuristic  Search  Method 
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Chapter  3 

Using  the  Heuristic  Search  Method 

When  AI  researchers  design  intelligent  programs,  they  draw  upon  a  repertoire  of  general 
operationalization  techniques,  including  the  "weak  methods"  of  gcncrate-and-test.  hill-climbing, 
heuristic  search,  matching,  and  means-end  analysis  abstractly  formalized  by  Newell  as  data-flow 
graphs  [Newell  69],  An  important  skill  in  designing  such  programs  is  the  ability  to  take  a  problem 
expressed  in  the  language  of  a  particular  task  domain  and  operationalize  it  in  terms  of  one  of  these 
methods. 

'1'his  process  can  be  viewed  as  mapping  die  problem  into  a  call  on  a  general  procedure  for  an  AI 
method  (heuristic  search,  for  example)  by  finding  suitable  values  for  die  arguments  (which  may 
include  generators,  tests,  and  orderings  for  controlling  the  search).  This  is  essentially  what  it  means 
to  formulate  a  problem  like  “avoid  taking  points"  or  "compose  a  cantus  fmnus "  in  terms  of  a 
heuristic  search,  and  relatively  little  has  been  accomplished  toward  getting  computers  to  do  it 
automatically.  Moore  encoded  Newell's  description  of  heuristic  search  as  a  MERLIN  schema  [Moore 
71)  and  instantiated  it  to  represent  the  Logic  T  heorist  [Newell  57]  program.  The  resulting  structure 
was  operational  in  dial  MHRLIN  could  prove  theorems  by  executing  it.  but  dv  instantiation  process 
by  which  this  structure  was  constructed  -  i.c.,  the  derivation  of  the  appropriate  generators  and  tests 
from  the  1. 1'  specifications  --  was  carried  out  by  hand. 

Perhaps  the  most  advanced  effort  so  far  toward  automatic  application  of  AI  techniques  is  die 
UNDERSTAND  program  [Simon  77],  which  reads  an  E.nglish  description  of  die  Tower  of  Hanoi 
problem  and  operationalizes  it  as  a  means-end  analysis  problem  by  constructing  an  appropriate  state 
space  representation  and  associated  operators. 

Mechanizing  the  application  of  an  AI  method  raises  several  questions: 

How  to  represent  a  general  method  so  that  it  can  be  reasoned  about  mechanically 
How  to  mop  a  particular  problem  onto  the  general  problem  statement  for  the  method 
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How  to  fill  in  information  required  by  die  method  but  not  explicit  in  the  original  problem 
How  to  refine  the  solution  by  using  additional  knowledge  about  the  problem  domain 

This  chapter  explores  these  questions  for  the  heuristic  search  method  hereafter  abbreviated 
“HSM").  It  presents  some  concrete  answers  in  the  form  of  a  schematic  representation  of  HSM  and 
some  rules  that  operate  on  it.  and  illustrates  them  by  showing  how  they  are  used  to  operationalize  die 
Hearts  advice  “avoid  taking  points.”  The  generality  of  die  formulation  is  tested  by  applying  it  to  a 
simplified  music  composition  task. 


3.1.  A  Slightly  Non-Standard  Version  of  Heuristic  Search 


Newell  [Newell  69|  described  the  general  problem  statement  for  HSM  as  follows: 

Given:  a  set  f  .x} .  the  problem  space; 

a  set  of  operators  { with  range  and  domain  in  {  a  } ; 
an  initial  element,  .x^; 
a  desired  element,  .x 

u 

Find:  a  sequence  of  operators.  qr  q, . such  that  they  transform  .v  into  .x j. 

<?X./ 1-  V  V  -11  =  \i 


He  mentioned  some  variations: 

Initially,  a  sot  of  elements  may  be  given,  rather  than  just  one,  with  the  search  able  to  start  from 
any  of  them.  Likewise,  finding  any  one  of  a  set  of  elements  can  be  desired,  rather  than  just 
finding  a  single  one.  This  final  element  (or  set)  can  be  given  by  a  test  instead  of  by  an  element 
...  die  operators  need  not  involve  only  a  single  input  and  a  single  output. 


He  described  the  heuristic  search  procedure  as  follows: 

The  initial  element  x  is  die  initial  current  position:  operators  are  selected  and  applied  to  it; 
each  new  element  is  compared  with  x  .  to  see  whether  the  problem  is  solved:  if  not,  it  is  added 
to  a  list  of  obtained  positions  (also  called  die  “try  list"  or  die  "subprobiem  list"!;  and  one  of 
these  positions  is  selected  from  which  to  continue  die  search....  The  search  is  guided  (:.e„  die 
tree  pruned)  by  appropriate  selection  and  rejection  of  operators  and  elements. 


IOO  uses  a  somewhat  different  formulation  of  HSM  in  which  everything  is  expressed  in  terms  of 
(operator)  sequences,  called  pei/is.  The  search  procedure  extends  a  path  by  explicitly  appending  an 
operator  to  it;  the  fact  diat  operators  map  one  state  to  another  is  implicit  in  the  tests  applied  to  paths, 
i.e..  operators  are  not  functionally  applied  to  states.  This  procedure  can  be  described  by  modifying 
Newell's  description  (differences  arc  underlined): 
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The  null  oath  is  the  initial  current  position;  choice  elements  are  selected  and  appended  to  it; 
each  new  path  is  tested  to  sec  whether  the  problem  is  solved;  if  not,  it  is  added  to  a  list  of  paths; 
and  one  of  these  oaths  is  selected  from  which  to  continue  the  search.  The  search  is  guided  by 
appropriate  selection  and  rejection  of  choice  elements  and  paths. 

The  choice  elements  need  not  be  operators;  this  procedure  can  be  applied  to  any  problem  of  the 

form 

Find  a  sequence  of  choices  satisfying  a  given  criterion. 

Thus  the  first  step  in  operationalizing  a  problem  in  terms  of  HSM  is  to  identify  the  sequence  of 
choice  points  involved  and  the  set  of  admissible  alternatives  at  each  one,  and  to  reformulate  the 
solution  criterion  as  a  computable  predicate  on  the  choice  sequence.  This  provides  enough 
information  to  specify  an  executable  but  inefficient  {i.e.,  combinatorially  explosive)  generate-ami-tesl 
search  procedure,  shown  in  Figure  3-1  as  a  data-flow  graph.  Such  a  procedure  can  then  be  refined 
into  a  genuine  heuristic  search,  shown  in  Figure  3-2.  by  reorganizing  die  search  process  so  that 
constraints  on  tire  overall  solution  are  applied  as  early  as  possible  in  the  search;  to  order  or  reject 
paths,  to  order  or  filter  tire  generation  of  alternatives  at  each  choice  point,  and  even  to  reduce  the 
depth  or  breadth  of  the  search  space  itself. 

3.1.1.  Overview 

The  remainder  of  the  chapter  is  organized  as  follows.  (§3.2)  describes  a  generic  heuristic  search 
procedure  and  a  corresponding  schematic  representation  of  HSM.  Slots  in  die  schema  correspond  to 
problem-specific  components  of  this  procedure,  such  as  the  tests  used  to  prune  paths.  (§3.3) 
illustrates  the  mechanical  instantiation  of  the  HSM  schema  for  the  "avoid  taking  points"  example, 
and  describes  the  initial  “naive"  (inefficient)  search  it  yields.  (§3.4)  shows  how  diis  solution  can  be 
iteratively  refined  using  knowledge  about  the  domain  and  analysis  of  die  search  criterion.  (§3.5) 
applies  the  whole  process  to  an  example  from  die  domain  of  music  composition,  and  (§3.6)  draws 
some  conclusions  about  the  generality  of  the  approach. 
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CHOICE 

SET 


(function  of  path) 


Figure  3-1:  Generatc-and-Test  Procedure 


§3.2.  A  Schematic  Representation  of  HSM 
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PATH 


CHOICE 

SET 


(function  of  path) 


Figure  3-2:  Generic  Heuristic  Search  Procedure 
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3.2.  A  Schematic  Representation  of  HSM 


According  to  the  slightly  non-standard  formulation  of  HSM  used  in  t'00.  its  purpose  is  to 
Find  a  sequence  satisfying  a  given  criterion. 


Thus  the  search  space  for  HSM  contains  partial  sequences  or  paths.  The  search  proceeds  by 
selecting  from  a  list  of  paths  under  consideration,  extending  the  chosen  path  by  an  element  chosen 
from  a  set  of  alternatives,  and  testing  if  the  extended  path  satisfies  the  search  criterion.  If  so,  die 
search  halts  successfully;  otherwise,  the  path  is  added  to  the  active  path  list.  A  padi  is  remo'.ed  from 
the  active  list  if  all  its  extensions  have  been  considered  or  it  can  be  determined  not  to  lead  to  a 
solution.  ’Hi is  cycle  repeats  until  a  solution  is  found  or  the  list  is  exhausted. 


This  rough  description  provides  enough  context  to  describe  the  key  components  of  roo's  HSM 
schema. 

The  search  starts  with  a  single  path,  the  initial-path. 

The  alternative  extensions  for  a  path  are  given  by  die  choice-set  function.  Since  the  range  of 
choices  may  vary  at  different  points  in  the  search,  this  function  takes  as  its  argument  an  index 
that  identifies  a  particular  choice  point. 

flic  order  in  which  alternative  extensions  arc  generated  is  controlled  by  a  step-order,  a 
predicate  on  sequence  elements.  Klemcnts  satisfying  this  predicate  are  considered  before 
others.  The  step-order  is  represented  as  a  unary  predicate  rather  dian  a  binary  ordering  relation 
for  simplicity.  An  arbitrary  ordering  on  the  choice  set  could  be  expressed  as  a  fuz/.v  unary 
predicate:  extensions  that  satisfied  the  predicate  relatively  well  would  be  considered  before 
those  satisfying  it  to  a  lesser  degree. 

The  sec  of  extensions  generated  for  a  given  padi  is  filtered  by  a  step-test  predicate:  thus  the 
extensions  to  a  given  path  are  enumerated  by  a  gcncratc-and-test  process,  with  the  choice-set 
function  as  the  generator  and  die  step-test  predicate  as  the  test.  Since  the  step- test  and  stop- 
order  predicates  may  depend  on  the  path  being  extended,  they  take  a  path  index  as  a  second 
argument. 

The  order  in  which  paths  arc  selected  for  extension  is  controlled  by  a  path-order  predicate  on 
paths;  paths  satisfying  this  predicate  are  considered  first. 

A  new  ly  generated  path  must  satisfy  a  path-test  in  order  to  be  added  to  tire  active  list. 

A  solution  path  must  satisfy  both  a  solution-test  based  on  the  search  criterion,  and  a 
completion-test  that  checks  if  the  path  covers  the  complete  sequence  of  choice  points. 


The  generic  heuristic  search  procedure  shown  in  Figure  3-2  can  now  be  specified  more  precisely: 

1.  The  first  path  is  the  initial-path. 

2.  If  the  path  satisfies  the  path-test,  insert  it  in  the  active  path  list. 


§3.2.  A  Si-hcmatic  Representation  ot'HSM 


125 


3.  Choose  a  path  from  the  active  list,  preferably  one  that  satisfies  the  path-order.  If  the  list  is 
empty  the  search  has  failed. 

4.  Choose  a  pros iously  untried  choice  element  from  the  choice-set.  preferably  satisfying  the  step* 

*  order.  If  all  extensions  of  the  path  have  been  tried,  remove  it  from  die  active  list  and  go  back  to 
step  3. 

5.  If  the  choice  element  fails  the  step-test,  go  back  to  stop  4  and  try  again. 

6.  Extend  the  path  by  appending  the  choice  element  to  it.  If  the  extended  path  satisfies  the 

^  solution-test  and  completion-test,  it's  a  solution.  Otherwise  go  to  step  2. 

I  have  not  actually  implemented  this  procedure  but  see  no  conceptual  obstacles  to  doing  so. 
Execution  of  die  procedure  would  require  the  ability  to  evaluate  expressions  defined  in  terms  of  the 
runtime  task  environment,  tig..  (CARDS- IN-hand  me)  and  (SUIT-LED).  The  focus  of  this  chapter  is 
not  on  the  procedure  itself  but  on  die  process  by  which  a  problem  is  operationalized  in  terms  of  an 
appropriate  call  on  the  procedure. 

3.3.  Instantiating  the  HSM  Schema  for  a  Given  Problem 

The  purpose  of  HSM  is  to 

Find  a  sequence  of  choices  satisfying  a  given  criterion. 

There  are  several  steps  involved  in  mapping  a  particular  problem  like  "avoid  taking  points"  onto 
this  general  piohlem  sta'cincnt: 

1.  Reformulate  the  problem  to  make  it  possible  to 

2.  Recognise  die  problem  as  potentially  amenable  to  HSM  ;  dien 

3.  Identify  die  choice  sequence  for  die  problem  and 

4.  Express  the  search  criterion  as  a  function  of  the  choice  sequence. 

♦ 

Given  the  choice  sequence  and  search  criterion  for  die  problem,  die  HSM  schema  can  be 
instantiated  to  formulate  a  crude  but  executable  search. 

t  3.3.1.  Mapping  a  Problem  onto  the  l  ISM  Problem  Statement 

The  first  step  in  mapping  "avoid  taking  points"  onto  die  HSM  problem  statement  is  to  reformulate 
it  so  the  applicability  of  HSM  becomes  manifest,  as  illustrated  in  die  following  excerpt  from 
t  DER1V2.  die  derivation  for  die  "avoid  taking  points"  example; 


* 

4 


126 


§3.  Using  clio  Heuristic  Search  Method 


(AVOID- TAKING -POINTS  (TRICK)) 

2:1  ---  [ELABORATE  by  RULE  124]  ---> 

(AVOIO  (TAKE-POINTS  ME;  (TRICK)) 

2:2  ---  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 


The  relevance  of  HSM  to  the  reformulated  problem  is  indicated  by  a  general  rule: 

Use  heuristic  search  to  evaluate  a  predicate  on  a  scenario  in  which  choices  are  made. 


In  the  case  at  hand,  (TRICK)  is  the  scenario  in  which  choices  are  made.  In  LOO,  the  mle  is 

'  RLLF306:  (P...e.„) 

■>  (HSM  with  (problem  :  (P  ...  e  ...)) 

(object :  c) 

(chuice-seq  :  (choice-scq-of  c))) 
if  e  contains  an  event  sequence  w  ith  choices  in  it 


In  RULH306,  the  names  "problem,”  "object,"  and  "choice-seq"  denote  components  of  the  HSM 
schema:  respectively,  the  expression  to  be  evaluated,  the  scenario  referred  to  in  the  expression,  and 
the  sequence  of  choice  points  in  the  scenario. 

TOO  recognizes  that  (OURING  (TRICK)  (take-points  me  ))  is  a  predicate  on  the  scenario 

(TRICK)  =  (SCENARIO  (EACH  P  (PLAYERS)  (PLAY-CARD  P) ) 

(TAKE-TRICK  (TRICK- WINNER))) 

The  sequence  (EACH  p  (PLAYERS)  (PLAY-CARD  P) )  in  this  scenario  contains  the  event 
(PLAY-CARD  P)  =  (CHOOSE  C  (LEGALCARDS  P)  (PLAY  P  C) ) 


This  enables  FOO  to  identify  the  expression  (DURING  (TRICK)  (TAKE-POINTS  ME))  as  a 

predicate  on  a  scenario  in  which  choices  are  made.  RUI.H306  suggests  using  HSM  to  evaluate  this 

expression,  Le..  to  determine  whether  there  is  some  sequence  of  choices  satisfying  the  predicate. 

Applying  RUUU306  produces  a  partial  instantiation  of  the  HSM  schema: 

(DURING  (TRICK)  (TAKE-POINTS  ME)) 

2:3  ---  [by  RULE306 ]  ---> 

HSM  1 

(HSM1  <-  PROBLEM  :  (DURING  (TRICK)  (TAKE-POINTS  ME)}) 

( HSM  1  <-  08JECT  :  (TRICK)) 

( HSM  1  <-  CHOICE-SEQ  :  (CHOICE-SEQ-OF  (TRICK))) 


The  notation  above  reflects  the  fact  that  this  step  is  not  simply  a  transformation  from  the 
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expression  (DURING  (TRICK)  (TAKE-POINTS  ME) )  to  the  symbol  HSM l:  in  addition,  values  are 
filled  in  for  three  of  HSMl's  components,  as  indicated  by  the  parenthetical  assignments  shown  after 
the  transformation.  As  LISP  users  might  expect,  such  assignments  are  implemented  in  TOO  by 
putting  component-value  pairs  on  the  property  list  of  the  atom  HSM1. 


3.3.2.  Finding  the  Sequence  of  Choices  that  Affect  the  Predicate 


The  next  step  is  to  analyze  die  definition  of  trick  to  identify  the  sequence  of  choices  involved: 
( CHOICE -SEQ-OF  (TRICK))) 

2:5-13  ---  [RULE307-309 ,  analysis]  ---> 

(EACH  PI  (PLAYERS) 

(CHOOSE  (CARD-OF  PI) 

(LEGALCAROS  PI) 

(PLAY  PI  (CARO-OF  PI)))) 


The  CHOICE-SEQ-OF  function  projects  an  event  sequence  onto  the  subsequence  of  events  tint  are 
choice  events.  It  is  computed  by  expanding  the  definition  of  TRICK  and  applying  some  rules  for 
extracting  choice  sequences  from  event  descriptions: 

RU1.H307:  (choice-seq-of(each  x  S  Kx))  ->  (apply  append  (each  x  S  (choicc-seq-of  F.x))) 

RLT.E308:  (choice-seq-o&s)  ->  nil  if  s  involves  no  choice 

RL' 1.1:309:  (choice-seq-of (choose  x  S  F.x))  ->  (list  (choose  x  S  Fx)) 


Several  components  of  the  HSM  schema  can  now  be  instantiated: 


2:15  --- 
(HSM1  <- 
( HSM 1  <- 
( HSM  1  <- 
( HSM  1  <- 
(HSM1  <- 
( HSM1  <- 
( HSM  1  <- 
( HSM1  <- 
( HSM1  <- 


[ELABORATE  by  RULE 311]  — -> 

SEQUENCE  :  CARD-OF) 

CHOICES  :  (PROJECT  CARD-OF  (PLAYERS))) 
CHOICE-SETS  :  ( LAM80A  (PI)  (LEGALCARDS  PI))) 
INDICES  :  (PLAYERS)) 

INOEX  :  PI) 

VARIABLES  :  NIL) 

BINDINGS  :  NIL) 

INITIAL-PATH  :  NIL) 

COMPLETION-TEST  : 

( LAM8DA  (PATH)  (=  (tt  PATH)  (#  (PLAYERS))))) 


This  is  done  by  extracting  them  from  die  choice  sequence  description  or  using  default  values: 


§3.  Using  the  Heuristic  Search  Method 

(HSM  with  choicc-scq  :  (each  x  indices  (choose  (f'x)  S  A)))) 

(HSM  with  (sequence  :  0  --function  from  index  to  choice  point 

(choices  :  (project  f  indices))  -  sequence  of  chosen  objects 
(choice-sets  :  (lambda  (x)  S))  --  choice  set  at  choice  point  x 
(indices :  indices)  -  choice  point  indexing  sequence 
(index  :  x)  -  choice  point  index  variable 
(variables  :  nil)  -  (initially  empty)  list  of  temporary  variables 
(bindings  :  nil)  --  corresponding  list  of  values 
(initial-path  :  ntl)  -  default  start  state  for  search 
(completion-test : 

(lambda (path) ( =  (it  path)(#  indices))))) 

—  test  if  path  covers  enure  choice  sequence 

Some  of  these  components,  e.g.,  CHOICES,  are  not  directly  used  by  die  search  procedure,  but  are 
used  by  rules  that  instantiate  odicr  components. 

3.3.3.  Reformulating  the  Search  Criterion  in  terms  of  the  Choice  Sequence 

At  this  point  the  card  sequence  for  the  trick  has  been  identified  as  the  choice  sequence  in  the  HSM 
problem  statement 

Find  a  sequence  of  choices  satisfying  a  given  criterion. 

Accordingly,  die  value  of  die  CHOICES  component  in  die  HSM  schema  has  been  filled  in  as 

(PROJECT  CARD-OF  (PLAYERS) ),  otherwise  known  as  (cards- played).  It  remains  to  reformulate 

the  search  criterion  as  an  evaluable  predicate  on  this  sequence,  Lc..  to  solve  the  problem: 

(REFORMULATE  (DURING  (TRICK)  (TAKE-POINTS  ME)) 

(CARDS-PLAYED) ) 

Re-expressing  the  search  criterion  in  terms  of  ( CARDS-PLAYED)  involves  a  whole  separate 
derivation  over  40  steps  long,  summarized  below  and  corresponding  approximately  to  steps  6:3-39 
of  DF.R1V6. 

First  die  definition  of  TRICK  is  expanded: 

(DURING  (TRICK)  (TAKE-POINTS  ME)) 

---  [ELABORATE  by  RULE  124]  ---> 

(DURING  (SCENARIO 

(EACH  PI  (PLAYERS)  (PLAY-CARD  Pt)) 

(TAKE-TRICK  (TRICK-WINNER)}) 

(TAKE-POINTS  ME))) 
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This  step  is  performed  by 

RULE124:  (f  e; ...  en)  ->  c’,  where  f  is  defined  as  (lambda  (x j ...  xn)  e) 
and  c'  is  the  result  of  substituting  ...  en  for  x,  ...  xn  throughout  e 


Here  f  =  TRICK. 


Next  the  expression  is  analyzed  to  determine  which  properties  of  the  card  played  by  player  ME  may 
cause  player  ME  to  take  points.  Case  analysis  is  used  to  figure  out  that  player  ME  can  only  take  points 
by  winning  the  trick.  First  die  expression  is  split  into  two  cases: 

( OUR  I  MG  (SCENARIO 

(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME))) 

---  [DISTRIBUTE  by  RULE 2 84]  ---> 

(OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)] 

[DURING  (TAKE-TRICK  ( TR ICK- WINNE R ) )  (TAKE-POINTS  ME)]) 


This  split  is  suggested  by 


RUI.F.2S4:  (f ...  (+  e,  ...  cn> ...)  ->  ( +  ’  (f ...  e,  ...) ...  (f ...  en  ...)) 

where  +  and  + '  are  addition-like  operators  over  the  domain  and  range  of  f,  respectively,  and  f 
satisfies  die  homomorphism  identity  f[...  x  +  y  ...)  =  rf...  x  ...)  +'  fi.--  y  •••) 


Here  f  =  DURING,  +  =  SCENARIO,  and  +’  =  OR. 


The  first  case  is  eliminated  by  figuring  out  that  a  TAKE-POINTS  event  can’t  occur  during  a 

sequence  consisting  exclusively  of  PLAY-CARD  events: 

(DURING  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)]  [ TAKE - POI NTS  ME]) 

---  [COMPUTE  by  RULE57]  ---> 

NIL 

This  is  accomplished  by 

RCLH57:  (during  s  c)  ->  nil  if  s  and  e  have  no  common  sub-events 

RLT.F57’s  condition  is  evaluated  by  an  intersection  search  through  the  space  of  defined  concepts 
for  a  common  sub-cvcnt  of  s  and  e.  The  sub-events  of  an  event  consist  of  die  action  concepts  in 
terms  of  which  it’s  defined.  Thus  TAKE  is  a  sub-event  of 

TAKE-POINTS  *  ( LAM80A  (P)  (FOR-SOME  Cl  ( POINT-CAROS )  (TAKE  P  Cl))) 
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Similarly,  PLAY  is  the  only  sub-event  of 

PLAY-CARD  =  (LAMBDA  (P)  (CHOOSE  Cl  (LEGALCARDS  P)  (PLAY  P  Cl))) 


The  concepts  TAKE-  TR ICK  and  TAKE -POINTS  have  the  common  sub-event  TAKE.  Plugging  in  their 

definitions  and  moving  some  quantifiers  around  yields: 

(DURING  [TAKE-TRICK  (TRICK-WINNER)]  [TAKE-POINTS  ME]) 

—  [by  analysis]  — > 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CAROS) 

(DURING  [TAKE  ( TR ICK-WINNER )  C3]  [TAKE  ME  Cl]))) 


100  has  no  definition  for  the  DURING  predicate,  but  knows  it’s  reflexive,  and  can  therefore  partial- 
match(TAKE  (TRICK-WINNER)  C3)  against  ( TAKE  ME  Cl)  using 

RULE43:  (R  (f  e^ ...  e  )  (fe^  ...  cn'))  ->  (and  [=  e(  Cj'j ...  [=  en  en'])  if  R  is  reflexive 


Here  R  =  DURING  and  f  =  TAKE.  This  produces  a  quantified  conjunction  of  equalities: 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CAROS) 

(DURING  [TAKE  ( TR ICK-WI NNER )  C3]  [TAKE  ME  Cl]))) 

---  [REDUCE  by  RULE43]  ---> 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(AND  [=  (TRICK-WINNER)  ME]  [=  C3  Cl]))) 


The  quantification  over  Cl  is  eliminated  to  produce 

(AND  [EXISTS  C3  (CARDS-PLAYED)  (HAS-POINTS  C3)] 
[=  (TRICK-WINNER)  ME]) 


The  first  conjunct  in  this  expression  is  recognized  in  terms  of  the  concept  HAVE-POINTS: 

(EXISTS  C3  (CARDS-PLAYED)  (HAS-FOINTS  C3)) 

---  [RECOGNIZE  by  RULE123]  ---> 

(HAVE-POINTS  (CAROS-PLAYED) ) 


Tliis  recognition  is  accomplished  by 

RULE123:  c  ->  (fc(  ...  cn)  if  f  is  defined  as(lambda(xt ...  xn)<body>) 
and  e  is  the  result  of  substituting  eL ...  cn  for  ...  x  throughout  <body> 


Here  f =  HAVE-POINTS. 


The  second  conjunct  is  transformed  into  a  condition  on  ( CARD-0  F  ME )  by  analyzing  the  definition 


of  TRICK-WINNER: 


§3.3.3.  Reformulating  the  Search  Criterion  in  terms  of  the  Choice  Sequence 
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(  =  ( TRICK-WINNER)  ME) 

—  [by  analysis]  — > 

(=  (CAR0-0f  ME)  (HIGHEST-IN-SUIT-LED  (CARDS-PLAYED))) 


At  this  point,  the  original  search  criterion  (DURING  (TRICK)  (TAKE-POINTS  ME))  has  been 

rephrased  in  terms  of  (CAROS- PLAYED): 

(AND  [HAVE-POINTS  (CARDS-PLAYED)] 

[=  (CARD-OF  ME)  ( H IGHEST - IN- SUIT  -  LED  (CARDS-PLAYED))]) 


The  analysis  techniques  used  in  die  derivation  sketched  above  are  described  in  detail 

elsewhere  (§5).  Ihc  desired  solution-test  can  now  be  extracted  from  the  reformulated  problem: 

(REFORMULATE  (AND  [HAVE-POINTS  (CARDS  -  PL AYED ) ] 

[=  (CARD-OF  ME) 

(HIGHEST- IN-SUIT -LED  (CARDS-PLAYED) )] ) 
(CARDS-PLAYED)) 

2:19-21  -  [by  analysis]  - > 

([LAMBDA  (CARDS-PLAYED1) 

(ANO  [HAVE-POINTS  CARDS-PLAYED1] 

[=  ( CARDS- PLAYED1  ME) 

(HIGHEST -IN-SUIT -LEO  CARDS  -  PLAYED  1 )]) ] 

(CARCS-PLAYED)) 


i  00  uses  this  predicate  as  the  solution-test  component  of  the  HSM  schema,  and  fills  in  default 

values  for  the  step  and  path  constraints: 

( HSM 1  <-  SOLUTION-TEST  : 

(LAMBOA  ( CARDS-PLAYED1 ) 

(AND  [HAVE-POINTS  CARDS-PLAYED1] 

[  =  ( CARDS- PLAYED  1  ME) 

(HIGHEST- IN-SUIT -LED  CARDS- PLAYED  1 )])) ) 

(HSM1  <-  PATH-TEST  :  T) 

( HSM  1  <-  PATH-ORDER  :  NIL) 

( HSM 1  v  —  STEP-TEST  :  T) 

( HSM  1  STEP-ORDER  :  NIL) 
t  HSM  1  S-  PATH  :  CARDS  -  PLAYED  1 ) 


1  his  is  accomplished  by 

KL1  (J)SMwith  (reformulated-problem  :  ({lambda  (s)  I’s]  choices))) 

->  ( 1  ISM  with  (solution-test :  (lambda  (s)  Ps)) 

(puih-iost :  1 )  -  . icfauh  is  unpruned  smirch 
(path-order :  nil)  --  default  is  unarJered  search 
(step-test :  T)  -  default  is  unpruned  choice  set 
(step-order :  nil)  -  default  is  unordered  choice  set 
(path  :  s)>  -  path  variable 


Note  that  the  default  values  don't  represent  assumed  typical  cases  (as  they  do  in  some  knowledge 
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representation  schemes),  but  simply  provide  initial  values  that  may  subsequently  be  refined  by  the 
application  of  additional  knowledge.  For  example,  (PATH-TEST  :  T)  means  that  no  paths  are 
pained,  and  (PATH-OROER  :  NIL)  imposes  no  ordering  on  the  selection  of  paths. 


3.3.4.  Correcting  the  Initial  Formulation  of  the  Search 


The  HSM  schema  has  so  far  been  instantiated  as  follows  (omitting  components  used  only  during 
the  instantiation  process  itself): 

(HSMl  WITH 

(CHOICE-SETS  :  (LAMBDA  (PI)  (LEGALCARDS  PI))) 

(COMPLETION-TEST  : 

(LAMBDA  (PATH)  (  =  (#  PATH)  (#  (PLAYERS))))) 

(STEP-ORDER  :  NIL) 

(STEP-TEST  :  T) 

(PATH-ORDER  :  NIL) 

(PATH-TEST  :  T) 

(SOLUTION-TEST  : 

(LAMBDA  (CARDS-PLAYED1) 

(AND  [HAVE-POINTS  CARDS-PLAYED1] 

[=  (CARDS-PLAYED1  ME) 

(HIGHEST- IN-SUIT -LED  CARDS -PLAYED  1 ) ] ) ) ) 
(INITIAL-PATH  :  NIL)) 


This  is  not  quite  operational:  the  generator  function  (LAMBDA  (Pi)  (LEGALCARDS  pi)))  is 
generally  uncomputabie,  since  player  me  may  not  look  at  opponents’  cards.  (Detecting  this  problem 
automatically  would  require  a  model  that  could  predict  what  information  would  be  available  to 
player  me  at  a  given  point  in  the  game  (§8.1.1).)  The  problem  is  solved  as  follows: 

(LEGALCARDS  PI) 

2:24  ---  [ELABORATE  by  RULE  124]  ---> 

(SET-OF  C2  (CARDS)  (LEGAL  PI  C2)) 

2:26  ---  [by  RULE318]  ---> 

(SET-OF  C2  (CARDS)  (POSSIBLE  (LEGAL  PI  C2))) 


The  condition  ( POSSIBLE  P)  is  tnie  unless  P  is  known  to  be  false  (§2.6.3).  The  revised  generator 
function  is  computable  but  too  unconstrained:  tire  enure  deck  of  cards  will  be  considered  as  possible 
choices  for  each  player  unless  effective  tests  can  be  found  with  which  to  reject  impossible  choices.  To 
find  such  tests.  (OO  first  expands  the  definition  of  LEGAL: 

(LEGAL  PI  C2) 

2:27  ---  [ELABORATE  by  RULE124]  ---> 

(AND  [HAS  PI  C2 ] 

[«>  (LEADING  PI) 

(OR  [CAN-LEAD-HEARTS  PI]  [NEQ  (SUIT-OF  C2)  H])] 

[*>  (FOLLOWING  PI) 

(OR  [VOID  PI  ( SUIT-LEO) ]  [IN-SUIT  C2  (SU IT -LEO  )  ] ) ] ) 


§3.3.4.  Correcting  the  Initial  Formulation  of  tire  Search 
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Since  player  ME  can't  inspect  opponents'  hands,  the  sub-expression  (HAS  PI  C2)  is  not  directly 

evaluable.  By  an  interesting  process  described  more  fully  elsewhere  (§2.6.3)  (§2.6.3),  100  finds 

evaluable  necessary  conditions  on  (HAS  Pi  C 2 )  and  attaches  them  as  annotations,  as  indicated  by 

the  notation  “<exprcssion>  <- ;  <annotation>": 

2:28-39  ---  [by  RULE319,  analysis]  ---> 

((MAS  PI  C2)  <-  ; 

(=>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME)))) 

2:40-57  ---  [by  RULE319 ,  analysis]  ---> 

((HAS  PI  C2)  <-  ; 

(=>  (NON-VOIO  Pt)  IF  (IN-SUIT  C2  (SUIT-LED)))) 

l  assume  a  aintime  evaluation  mechanism  that  can  use  these  annotations  when  trying  to  evaluate 
the  annotated  expression.  For  instance,  to  evaluate  (HAS  pi  C2)  for  pi  in  (Opponents  me),  it 
would  check  (OUT  C2)  using  the  evaluation  method  derived  in  DERIV4  (§2.2).  A  card  is  OUT  if 
some  opponent  has  it.  Thus  if  (OUT  C2)  is  false.  PI  doesn't  have  C2  and  can’t  play  it.  This  prevents 
consideration  of  scenarios  in  which  a  curd  is  played  twice  or  an  opponent  plays  a  card  held  by  player 
ME.  A  similar  effect  would  be  produced  by  the  annotation 

((HAS  PI  C2 )  ;  (=>  (NON-VOIO  Pi)  IF  (IN-SUIT  C2  (SUIT-LEO ) ) ) ) 

This  would  prevent  consideration  of  scenarios  where  a  player  known  to  be  void  follows  suit. 

Such  necessary  conditions  arc  found  by 

RL'l.F.319:  P  <-:(  =  >  Q  IF  R)  ifQ's  definition  directly  or  indirectly  mentions  P, 
where  R  is  the  result  of  simplifying  (  =  >  P  Q) 

To  find  a  necessary  condition  for  P(et ...  e  J, 

Find  a  predicate  Q  whose  definition  mentions  P, 

And  solve  for  xl ...  x^  by  reducing  the  condition  P(e  ^ ...  ej  =  >  Q(Xj ...  x^). 

For  example,  to  find  a  necessary  condition  on  (HAS  PI  C2 ).  TOO  searches  the  knowledge  base  for 
predicates  defined  in  terms  of  HAS,  and  finds 

OUT  =  (LAMBOA  (C)  (EXISTS  P  (OPPONENTS  ME)  (HAS  P  C))) 

TOO  then  constructs  the  expression  (o  (OUT  C)  (HAS  PI  C2)),  which  reduces  bv  logical 
analysis  to  ( IN  Pi  (OPPONENTS  ME )),  provided  C  =  C2.  This  means  that  (OUT  C2 )  is  a  necessary 
condition  for  (HAS  Pi  C2)  whenever  (IN  Pi  (OPPONENTS  ME))  holds. 

The  generate-and-test  procedure  represented  by  the  corrected  initial  instantiation  of  the  HSM 
schema  corresponds  to  the  data-flow  graph  shown  in  Figure  3-3. 


134 


§3.  Using  the  Heuristic  Search  Method 


3.4.  Refining  HSM  by  Moving  Constraints  Between  Control 
Components 

In  mapping  a  problem  onto  HSM.  my  approach  is  to  start  with  a  "naive"  formulation  --  i.e„  one 
easy  to  derive  mechanically  --  and  then  refine  it  step  by  step  into  successively  better  solutions,  rattier 
than  trying  to  construct  a  sophisticated  formulation  right  off  the  bat.  This  general  approach  is 
illustrated  to  some  extent  in  DL-R1V9  (§2.3).  where  the  problem  is  to  decide  whether  a  player  is  void 
in  a  suit.  The  initial  formulation  of  that  problem  in  terms  of  the  disjoint  subsets  method  only  takes 
into  account  the  number  of  cards  left  in  cite  player's  hand,  but  it  is  then  refined  to  consider  in 
addiuon  the  number  of  cards  out  in  the  suit.  This  is  the  only  refinement  performed  in  DHH1V9.  In 
contrast,  refinements  account  for  most  of  die  process  of  formulating  a  problem  as  a  heuristic  search. 

In  FOO,  refinement  of  HSM  consists  of  transferring  a  constraint  from  one  control  component  to 
another  so  that  it  will  be  applied  at  an  earlier  point  in  die  search.  The  rest  of  this  section  illustrates 
dirce  kinds  of  refinements  corresponding  to  different  kinds  of  control  components  to  which  a 
constraint  can  be  moved: 

1.  Applying  a  test  earlier  in  the  search  reduces  the  branching  factor  of  die  search  by  pruning 
branches  that  can't  lead  to  a  solution. 

2.  The  search  space  can  be  reduced  in  depth  by  compiling  certain  constraints  into  input 
parameters  and  precomputed  functions  used  during  die  search. 

3.  Ordering  the  search  to  consider  die  most  promising  paths  llrst  helps  find  a  solution  path  faster 
when  one  exists. 

3.4.1.  Pruning  the  Search  by  Applying  Tests  Earlier 

A  general  strategy  for  refining  a  search  is  to 

Reduce  the  branching  factor  of  the  search  by  pruning  partial  paths  that  can 't  lead  to  a  solution. 

Clearly,  die  key  to  applying  this  strategy  is  to  identify  partial  paths  that  can't  lead  to  a  solution 
without  enumerating  all  the  ways  they  can  be  extended  into  complete  sequences. 

The  solution-test  tests  whether  a  complete  sequence  of  choices  satisfies  the  goal  of  the  search. 
Suppose  die  solution-test  requires  that  any  complete  sequence  s  satisfy  some  predicate  P(s),  where  if 
Pis)  holds,  so  must  P(s')  for  every  initial  subsequence  s'  of  s.  Then  any  path  diat  doesn't  satisfy  P  can 
safely  be  pruned  from  the  search,  since  it  can't  possibly  be  extended  into  a  solution  path.  A  predicate 
P  with  this  property  is  called  a  nnmotonicaily  necessary  condition  on  the  solution-test. 
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INITIAL 

PATH 

nil 


CHOICE  SET  =  possibly  legal  cards  of  current  player 


(function  of  path) 


-  out  if  player  is  opponent 
--  not  in  suit  led  if  player  is  void 


Figure  3-3:  Initial  Search  for  Avoid  Taking  Points 
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In  short,  if  a  necessary  condition  on  the  satisfiability  of  the  solution-test  (a  function  of  the  entire 
choice  sequence)  can  be  formulated  purely  as  a  function  on  a  path  (initial  subsequence  of  choices),  it 
can  be  incorporated  into  the  path-test,  Similarly,  if  a  necessary  condition  on  the  satisfiability  of  the 
path-test  can  be  formulated  as  a  test  on  alternative  path  extensions,  it  can  be  incorporated  into  the 
step-test.  For  example,  consider  the  initial  HSM  formulation  of  “avoid  taking  points."  where  the 
pa  tit- test  is  die  constant  predicate  (lambda  (s)  T).  or  T  for  short.  [1  have  relaxed  die  semantics  of 
lambda  calculus  to  allow  an  expression  e  to  be  treated  as  the  constant  function  (lambda  (x)  e).  Also.  I 
freely  use  boolean  operators  as  functionals:  thus  (and  [lambda  (x)  Px]  [lambda  (x)  Qx])  is  interpreted 
as  (lambda  (x)  (and  Px  Qx)).J  The  solution-test  is  the  predicate 

(LAMBDA  (CAROS-PLAYEOI ) 

(AND  [HAVE-POINTS  CAROS - PLAYED1 ] 

[=  ( CARDS- PLAYED1  ME) 

(HIGHEST- IN-SUIT-LED  CAROS-PLAYEDI}])) 


The  first  conjunct  in  dtis  expression  is  not  a  monotonically  necessary  condition,  since  a  card 
sequence  that  doesn't  have  points  can  be  extended  into  one  diat  does  simply  by  appending  a  point 
card  to  it.  However,  die  second  conjunct  is  a  monotonically  necessary  condition,  since  in  order  for  a 
card  sequence  CAROS-PLAYEOi  to  satisfy  the  conjunct  (cal!  it  P)  every  initial  subsequence  of 
CAROS-PLAYEDi  must  also  satisfy  P.  That  is,  in  order  for  player  ME's  card  to  be  the  highest  for  the 
whole  trick,  it  must  be  the  highest  a t  each  point  in  the  mck  (once  player  ME  has  played).  Actually,  a 
slight  qualification  is  required  to  make  P  a  true  monotonically  necessary  condition.  P  only  applies  to 
paths  in  which  player  ME  has  already  played  a  card,  since  (Cards-playedi  me)  is  undefined  for 
shorter  paths.  If  the  predicate  M  characterises  diose  padts  in  which  player  ME  has  already  played, 
then  (  =  >  M  P)  is  the  desired  monotonically  necessary  condition.  This  reasoning  produces  die 
refinement 

2:59-73  ---  [by  RULE323 ,  analysis]  ---> 

(HSM1  <-  PATH-TEST  : 

(LAM80A  (CAROS-PLAYEOI) 

(=>  [IN  ME  (IN0rCES-0F  CAROS-PLAYEDI)] 

[=  (CAROS-PLAYEOI  ME) 

( HIGHEST-  IfJ-SU  IT-LED  CAROS-PLAYEDI)]) ) ) 


The  general  rule  used  to  make  this  refinement  is 

RU1.E323:  (HSM  with  (solution -test :  (lambda  (s)  (and  ...  Ps  ...)) 

(path- test :  R)) 

->  (HSM  with  (path-test :  (and  R  (lambda  (s)  (  =  >  M  Ps))))) 

where  \I  is  the  result  of  simplifying  the  monotonicity  condition 
(forall  s'  (prefixes-of  s)  ( =  >  Ps  Ps')) 


// the  solution- test  includes  an  (almost)  monotonically  necessary  constraint  P 
Then  determine  the  condition  M  under  which  P  is  >nunoiontcally  necessary, 
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And  add  (  =  >  \f  P)  to  the  path- lest. 


In  the  above  example,  M  is  (IN  ME  (INOICES-OF  CARDS-PLAYEDl)).  Note  that  RUI.E323 

automatically  catches  (in  M)  the  sort  of  exceptions  a  programmer  often  forgets.  Such  details  are 

apparent  in  the  unwieldy  but  machine-understandable  expression  produced  by  moving  the  highest- 

card  constraint  from  the  path-test  to  the  step-test: 

2:74-92  ---  [by  RULE327,  analysis]  ---> 

( HSM1  <-  STEP-TEST  : 

(LAMBDA  (PI  C21 ) 

(=>  (NOT  (AFTER  ME  PI)) 

(AND  [=  (SUIT-OF  (CAROS-PLAYEDl  ME))  (SUIT-LED)] 

[=>  (=  (SUIT-OF  C21)  (SUIT-LED)) 

(NOT  (HIGHER  C21  ( CARDS- PLAYED  1  ME)))])))) 


The  effect  of  this  constraint  transfer  is  to  prevent  the  generation  of  paths  violating  the  highcst-card 
constraint,  not  just  pmne  away  already-generated  paths.  The  step-test  filters  the  alternatives  C2  2  at 
choice  point  PI  being  considered  as  extensions  to  the  path  CARDS-PLAYEDl.  and  rejects  cards  in  the 
suit  led  that  are  higher  than  player  ME’s  card.  In  general,  this  kind  of  refinement  reformulates  a 
constraint  on  a  path  as  a  constraint  on  a  single  choice  element  being  considered  as  a  potential  path 
extension.  In  the  latter  form,  the  constraint  may  be  cheaper  to  test.  If  only  choice  elements  that 
satisfy  this  constraint  are  used  as  path  extensions,  fewer  paths  will  be  generated.  The  reformulated 
constraint  represented  by  die  above  step-test  can  be  paraphrased  as  follows: 

If  player  Pi  does  not  precede  player  ME, 

then  only  consider  C21  as  an  extension  to  CARDS-PLAYEDl 

if  player  ME's  card  (in  card  sequence  CAROS-PLAYED  l)  is  in  die  suit  led, 

and  C2i  is  not  higher  dian  player  ME's  card  if  C 2 1  is  in  die  suit  led. 


The  effect  of  this  refinement  is  to  restrict  the  generation  of  scenarios  to  those  in  which  player  me 
takes  the  trick.  In  effect,  it  reduces  the  branching  factor  of  the  search,  Le..  the  number  of  alternative 
path  extensions  considered  at  each  choice  point. 


The  general  rule  for  moving  a  constraint  from  path-test  to  step-test  is 

RLLE327:  (HSM  with  (path-test :  (and  ...  [lambda  (s)  Ps]  ...)) 

(step-test :  R)) 

->  (HSM  <-  (step-test :  (and  R  [lambda  tic)  Qc]))) 
if  Ps  can  be  reformulated  as  (forall  i  (indiccs-of  s)  Qs() 

If  the  path- test  includes  a  constraint  Ps. 

and  Ps  is  equivalent  to  (forall  i  ( indices- of  s)  Qs )  for  some  predicate  Q. 
then  add  the  constraint  Qc  to  the  step-test. 
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RULF.327  applies  when  a  path-test  predicate  P  on  a  path  s  =  s,  ...  s;i  can  be  recast  as  a  conjunction 
of  the  form  (and  Qs^  ...  Qsn)  for  some  predicate  Q.  In  the  current  example,  s  is  CAROS-PLAYEDl  and 
Ps  is 

(=>  [IN  ME  (INOICES-OF  CAROS-PLAYEDl)] 

[=  (CAROS-PLAYEDl  ME)  (HIGHEST- IN-SUIT-LED  CARDS  -  PLAYED  1 )] ) 

To  apply  RLT.E327.  P  is  first  reformulated  in  the  universally  quantified  form  (forall  i  l...n  QSj). 
Then  c  =  C 2 1  is  substituted  for  s(  =  (CAROS-PLAYEOi  PI)  in  the  quantified  condition  QSj,  and  the 
resulting  expression  is  simplified  to  produce  Qc  = 

( =  >  (NOT  (AFTER  ME  PI)) 

(AND  [«  ( SU IT -OF  (CAROS-PLAYEDl  ME))  (SUIT-LED)] 

[=>  [  =  (SUIT-OF  C21)  (SUIT-LED)] 

[NOT  (HIGHER  C21  (CAROS-PLAYEDl  ME))]])) 

T  his  is  the  body  of  the  desired  step-test.  This  mechanically  derived  expression  is  a  bit  hard  to 
understand,  since  it  has  logical  connectives  nested  four  deep,  but  it  can  be  paraphrased  as  follows: 

If  you're  considering  possible  cards  for  player  P  l  in  a  path  where  player  ME  follows  suit, 
then  don't  consider  cards  in  the  suit  led  that  are  higher  than  player  ME's  card. 

3.4.2.  Reducing  the  Depth  of  the  Search 

Another  general  strategy  for  refining  a  search  is  to 

Reduce  the  depth  of  the  search  by  eliminating  one  or  more  choice  points. 

The  key  to  applying  this  strategy  is  to  use  additional  problem  constraints  to  compile  choices  out  of 
the  search. 

The  search  procedure  so  far  constructed  uses  the  expression  (SUIT-LED)  in  several  places.  This  is 
defined  as  (SUIT-OF  (CARO-QF  (LEADER) ) )  and  therefore  depends  on  the  indeterminate  quantity 
(CARDS-PLAYED).  To  make  die  procedure  operational,  diis  reference  must  be  eliminated.  One  way 
would  be  to  replace  (SUIT -LED)  with 

(SUIT-OF  (CAROS-PLAYEOI  (LEAOER ) )  ) 

The  value  of  this  expression  depends  on  the  particular  path  CARDS -played  1  being  considered, 
and  is  computed  by  using  ( LEADER )  as  an  index  into  dut  path.  However,  there  is  a  better  solution  if 
the  value  of  (SUIT-LED)  will  be  known  at  the  time  die  search  starts  (and  will  therefore  be  the  same 
for  all  paths  considered):  simply  use  that  value.  This  idea  is  illustrated  by  a  refinement  of  die  step- 
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(SUIT-LED) 

2:94  ---  [by  RULE333]  ---> 

SUIT-LED2 

(  HSM 1  <-  VARIABLES  :  (  SUI  T -I.ED2 )  ) 

(HSM1  <-  BINDINGS  :  ( ( SUIT-LED)) ) 

Here  SUIT-LED2  is  a  new  input  variable  which  will  be  bound  to  the  value  of  (SUIT-LED)  at  the 
time  of  the  search.  The  rule  for  this  is 

RUI.F.333:  (HSM  with  (step-test :(...  c  ...)) 

(sequence  :  f) 

(variables  :  (...)) 

(bindings  :  (...)» 

->  (HSM  with  (step-test :(...  v ...» 

(variables :  (v ...» 

(bindings :  (e ...))) 

if  e  is  defined  in  terms  of  f. 

If  a  sub-expression  P.f^  of  ike  step- test  refers  to  the  choice  sequence,  s. 

[But  the  value  off  s) "n  >/7  have  been  determined  by  the  time  the  search  begins.] 

Then  change  P,t ,  to  P ,  and  cache  the  value  off  s)  in  v  at  the  beginning  of  the  search. 

As  RUI.H333  is  currently  implemented,  the  bracketed  clause  is  not  tested,  since  LOO  lacks  a  model 
of  what  will  be  know  n  when.  Also,  the  substitution  is  performed  only  within  the  step-test  rather  than 
in  ail  the  constraint  components,  because  roo's  rule  syntax  does  not  provide  a  construct  for  iterating 
over  die  components  of  a  schema,  although  this  could  easily  be  corrected.  A  more  general  rule  would 
be: 

R L'l.t£333a:  Cache  a  choiee-sequence-dcpendent  expression  whose  value  won't  change  during  the 
search. 


Further  improvements  are  possible  by  exploiting  assumptions  about  when  and  why  the  search  will 
be  performed.  For  example,  die  purpose  of  the  search  is  to  help  player  ME  choose  a  card,  not  just  to 
predict  whether  there's  some  possible  scenario  in  which  ME  takes  points.  Consider  the  original  adv  ice 


(AVOID  (TAKE-POINTS  ME)  (TRICK))  = 

(ACHIEVE  (NOT  (DURING  [TRICK]  [TAKE-POINTS  ME])))  = 


(ACHIEVE  (NOT  (DURING  [SCENARIO  (EACH  Rt  (PLAYERS) 

(CHOOSE  (CARD-OF  PI)  (LEGALCARDS  Pi) 
(PLAY  PI  (CARD-OF  PI)))) 

(TAKE -TRICK  ( TRICK-DINNER ) ) ] 
[TAKE-POINTS  ME]))) 


The  search  evaluates  die  condition  (DURING  ...)  by  trying  to  find  a  value  for  the  nen- 
dcte.ministic  card  sequence  (PROJECT  CARD-OF  (PLAYERS))  dial  satisfies  the  condition.  However. 
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since  tins  condition  occurs  inside  the  expression  (ACHIEVE  .  .  . ),  the  implicit  purpose  of  die  search 
is  not  just  to  find  a  scenario  in  which  ME  takes  points,  hut  to  prevent  it  from  happening.  I  he 
condition  (DURING  [TRICK]  [TAKE-POINTS  ME])  implicitly  depends  on  the  card  chosen  by  die 
task  agent,  so  avoiding  points  means  constraining  the  choice  appropriately  (§2.7.1). 

This  context  sensitivity  is  a  weak  spot  in  1-OO’s  knowledge  representation,  caused  partly  by  the 
vaguely -defined  modal  semantics  of  ACHIEVE  and  partly  by  the  non-applicative  representation  of 
choice  ( §2.7).  It  creates  a  need  to  detect  implicit  interactions,  since  die  value  of  an  expression  may 
depend  on  a  variable  it  does  net  explicitly  mention.  Finding  such  interactions  may  involve  arbitrarily 
deep  expansion  of  definitions;  perhaps  it  could  be  done  efficiently  by  means  of  intersection  search 
through  the  knowledge  base  of  concept  definitions  (§5.6).  This  problem  resembles  the  aliasing 
problem  that  arises  in  verifying  programs  with  pointers,  where  the  value  of  one  variable  may 
implicitly  depend  on  die  value  of  another  [I.  uckham  79]. 

One  way  to  render  this  implicit  interaction  explicit  is  to  perform  the  search  separately  tor  each  ot 
player  ME-'s  cards,  and  decide  whether  playing  that  card  might  lead  to  taking  points,  this  involves 
modifying  the  search  procedure  so  that  it  takes  player  ME's  card  as  an  input,  and  doesn  t  treat 
(CAR0-0F  Pi)  asa  non-deterministic  variable  when  Pi  =  ME. 

Moreover,  since  the  search  vvill  not  be  performed  until  it's  time  for  player  ME  to  choose  a  card,  the 
cards  played  by  player  ME’s  predecessors  will  be  know  n.  These  ideas  arc  illustrated  in  refinements  on 
the  step- test: 

(CARDS-PLAYEOt  ME) 

2:93  ---  [5y  RULE332]  ---> 

MY-CARD4 

(HSM1  <-  INITIAL-PATH  :  (PROJECT  CARD-OF  (PREFIX  (PLAYERS)  ME))) 

(rtSMl  <-  BINDINGS  :  ((CARD-OF  ME)  (SUIT-LED))) 

(HSM1  <-  VARIABLES  :  (MY-CARD4  SUIT-LED2) ) 

Here  MY-CARD4  is  an  input  variable  which  will  be  bound  to  a  possible  value  of  (CARD-OF  ME) 
before  the  search  begins.  Taking  (CARD-OF  ME)  as  a  given  reduces  the  choice  sequence  from 
(EACH  PI  (PLAYERS)  (PLAY-CARO  PI))  to  (EACH  PI  (OPPONENTS  ME)  (PLAY-CARD  PI)). 
Dui  since  the  cards  played  by  player  ME's  predecessors  will  be  known  at  search  time,  die  choice 
sequence  can  be  further  reduced  to  { EACH  Pi  (PLAYERS-AFTER  me)  (PLAY-CARD  pi)).  lTis 
is  done  by  changing  the  initial-path  to  ( PROJECT  CARD-OF  (PREFIX  (PLAYERS)  ME)).  Now  the 
search  will  start  with  the  partial  trick  scenario  consisting  of  die  cards  played  by  everyone  up  to  and 
including  player  ME.  The  effect  of  this  refinement  is  to  reduce  the  depth  of  the  search  space.  i.e..  the 
number  of  sequential  choices  required  to  reach  i  solution.  The  general  rule  for  this  refinement  is 
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RLI.H332:  (HSMwith  (step-test :  (...  (f  x) ...))) 

(sequence :  f) 

(choices :  f ) 

(indices :  S» 

->  (HSMwith  (step-test :(...  v ...)) 

(variables :  (v  ...)) 

(bindings  :  ((f  x) ...)) 

(initial-path  :  (project  f  (prefix  S  x)))) 

Star!  the  search  at  the  point  following  any  choices  already  determined  before  search  lime. 


As  implemented.  RU.H332  (like  RL'LF.333)  revises  only  the  step-test,  rather  than  all  the  HSM 
schema  components,  although  Lhis  could  be  rectified  straightforwardly.  The  general  idea  of 
RLT.E332  can  be  stated  in  more  detail  as  follows: 

To  analyze  a  property  of  a  choice  fix^  in  a  choice  sequence  fix  ...  fixn), 
use  the  search  space  formed  by  the  choice  sequence  fix  ,) ...  fix  ). 
since  at  die  time  fix,)  is  chosen.  fix() ...  fix  j)  will  be  already  be  known. 


The  net  effect  of  the  two  refinements  on  the  step-test  is 

(HSMl  <-  STEP-TEST  : 

(LAMBDA  (PI  C 2 1 ) 

{=>  [HOT  (AFTER  ME  PI)] 

[AMO  [=  (SUIT-OF  MY -CARD 4 )  SUIT-LED2] 

[  =  >  [«  (SUIT-OF  C2I)  SUIT-LED2] 

[MOT  (HIGHER  C21  MY-CARD4) ]]]))) 


This  step-test  is  used  to  filter  the  generation  of  path  extensions.  It  works  as  follows: 

If  you're  considering  whether  to  extend  a  path  with  a  card  C2 1  played  by  player  PI, 
Where  pi  plays  after  player  ME, 

Make  sure  that  plater  ME's  card  is  in  the  suit  led. 

And  that  C 2 1  isn't  both  in  the  suit  led  and  higher  than  player  ME's  card. 


Given  that  the  search  starts  after  player  ME's  turn,  the  proviso  (MOT  (AFTER  ME  PI) )  will  be  true 
for  all  paths  considered,  and  therefore  superfluous.  It  would  be  superfluous  even  if  tire  search  started 
at  the  beginning  of  the  tn<  is.  thanks  to  substituting  MY-CARD4  for  (CARDS-PIAYED1  ME).  That  is,  if 
the  search  is  executed  separately  for  each  value  of  my-caroa.  the  step-test  can  be  used  to  avoid 
considering  cases  where  an  opponent  plays  a  card  higher  than  player  ME's.  even  f  the  opponent  plays 
before  player  Ml.  Generation  of  the  proviso  could  be  eliminated  altogether  by  applying  RUI.H332  to 
the  solution-test  before  moving  the  highcst-card  constraint  to  die  pad:- test  and  step-test. 

The  condition  (-  (SUIT-OF  MY-CARD4)  SUIT-LED2 )  is  independent  of  Pi,  C21.  and 
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CARDS-PLAYE01,  and  could  be  tested  just  once  at  the  beginning  of  the  search,  although  I  didn’t 
implement  a  rule  to  make  this  refinement.  This  could  be  done  by  incorporating  an  initial-test 
(applied  to  the  initial-path)  in  the  generic  heuristic  search  procedure  shown  in  Figure  3-2.  This 
illustrates  a  limitation  of  using  a  fixed  set  of  HSM  components:  one  can  always  invent  refinements 
that  involve  adding  new  components.  A  more  powerful  approach  would  allow  refinement  rules 
expressed  as  transformations  on  data  flow  graphs.  This  is  essentially  the  approach  proposed  by 
Tappcl  [rappel  SO).  An  adequacy  criterion  for  a  scheme  along  these  lines  is  whether  it  can  represent 
the  heuristic  search  procedure  and  refinement  rules  presented  here. 

The  last  condition  restricts  the  generation  of  paths  u>  those  in  which  MY-CARD4  is  the  highest  card 
played  in  SUIT-LED2: 

(=>  [«  (SUIT-OF  C21 )  SUIT-LE02] 

[NOT  (HIGHER  C 2 1  MY-CAR04)]) 

Note  that  if  player  ME  leads  the  trick.  SUIT-LE02  must  be  bound  to  (SUIT-of  MY-CARQ4 )  before 
die  search  begins  in  order  for  everything  to  work.  This  detail  is  not  addressed  in  DFRIV2.  A  natural 
way  to  deal  with  it  would  be  to  split  the  whole  search  procedure  into  two  eases  depending  on  whether 
player  ME  leads  the  trick.  Hath  case  would  allow  refinements  appropriate  to  the  assumption  on  which 
it  was  based.  However,  this  would  amount  to  making  a  separate  copy  of  die  flow  graph  for  each  ease, 
a  transformation  that  violates  the  fixed-graph  limitation  just  discussed. 

3.4.3.  Ordering  the  Search  by  Predicting  Success 

A  diird  strategy  for  refining  a  search  is  to 

Order  the  search  to  consider  first  those  paths  most  iikely  to  lead  to  a  solution. 

The  key  to  applying  this  strategy  is  to  identify  partial  paths  likely  to  lead  to  a  solution  widiout 
actually  trying  to  extend  them  into  complete  sequences. 

The  refinements  described  so  far  have  been  concerned  with  pruning  branches  of  die  search  or 
eliminating  their  generation  in  the  first  place.  The  refinements  described  in  this  section  try  instead  to 
re-order  die  search  to  find  a  solution  faster,  assuming  one  exists.  The  approach  is  to  find  properties  of 
partial  solutions  diat  serve  as  predictors  of  success,  and  to  give  priority  to  paths  diat  exhibit  such 
properties,  which  are  analytically  derived  from  the  search  criterion. 


The  solution-test  for  the  "avoid  taking  points"  example  is 
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(LAMBDA  (CAR0S-PLAYED1) 

(AND  [HAVE-POINTS  CAROS -PLAYED  1 ] 

[=  (CARDS-PLAYED1  ME) 

(HIGHEST-IN-SUIT-LED  CARDS -PLAYED1 )]) ) 


As  mentioned  before,  die  second  conjunct  is  a  monoionicallv  necessary  condition ,  which  justifies  its 
incorporation  in  the  path-test  and  step-test.  But  the  first  conjunct  is  not:  aldiough  no  point  cards 
may  have  been  played  so  far  in  a  trick,  a  subsequent  player  might  play  one.  How'  then  can  diis 
constraint  be  exploited  earlier  in  the  search? 


The  answer  lies  in  die  fact  that  if  a  path  has  points,  so  do  all  its  possible  extensions.  Thus  other 

things  being  equal,  a  padi  with  points  is  more  likely  to  lead  to  a  solution  than  one  that  doesn't,  and  a 

solution  can  be  found  faster  by  considering  such  padis  first.  (Recall  that  a  "solution"  in  this  search  is 

a  card  sequence  for  die  trick  causing  player  ME  to  take  points.)  In  short,  die  conjunct 

( HAVE  -  POINTS  CAROS  -  PLAYED  1 )  is  a  monotonically  sufficient  condition  and  can  diercforc  be  used  as 

a  search-ordering  heuristic: 

2:96-100  ---  [by  RULE335 .  analysis]  ---> 

(HSMZ  <-  PATH-ORDER  : 

(LAMBDA  (CARDS-PLAYED1) 

(HAVE-POINTS  CAROS-PLAYED1 ) ) ) 

The  general  idea  behind  diis  refinement  is  expressed  by 

RUl  F335:  (HSM  with  (solution-test :  (lambda  (s) (and  ...  Ps  ...)))) 

->  (HSM  with  (path-order :  (lambda  (s)  Ps))) 

if  P  satisfies  the  monotonicity  condition  (forall  s'  (prefixes-of  s)  ( =  >  Ps'  Ps)). 

If  the  solution- test  includes  a  monotonically  sufficient  constraint  P 
Then  add  P  to  the  path-order. 


The  have-points  constraint  can  be  further  exploited  by  using  it  to  control  not  only  the  order  in 

which  existing  padis  arc  considered  but  also  the  order  in  which  padis  arc  generated  to  begin  with. 

For  example,  paths  with  points  can  be  generated  first  by  using  point  cards  before  non-point  cards 

when  extending  paths  in  which  no  points  have  yet  been  played.  This  reasoning  is  illustrated  in: 

2:101-105  ---  [by  RULE333 ,  analysis]  ---> 

( HSM 1  <-  STEP-ORDER  : 

(LAMBOA  (PI  C21) 

(OR  [HAVE-POINTS  CARDS  -  PLAYED  1 ]  [HAS-POINTS  C21]))) 


The  motivation  for  diis  step  is  diat  a  function  on  a  choice  element,  like  HAS-POINTS.  may  be 
cheaper  to  evaluate  than  a  function  on  a  path,  like  HAVE-POINTS,  since  it  requires  less  data.  That  is. 
testing  a  single  choice  element  should  be  faster  than  testing  a  sequence  of  them.  The  general  rule  for 
this  refinement  is 
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RULK338:  (IISM  with  (path-order :  (lambda  (s)  Ps))) 

->  (IIS.Mwith  (step-order :  (lambda  (i c) Qc))) 

where  Qc  is  the  result  of  s;  nplify  ing  (P  (append  s  (list  c))) 

If  the  path-order  contains  a  constraint  P  on  paths  x, ...  x^ 

And  P(x l ...  x.J  is  equivalent  to  Q(x  ^). 

Then  add  Q  to  the  step-order. 


An  extension  to  this  approach  would  enhance  the  data  structure  representation  of  a  path,  s,  to 
include  an  extra  bit,  B(s).  indicating  whether  s  has  points.  The  value  B(s')  for  a  new  path  s' 
constructed  by  appending  a  card  c  to  s  would  be  computed  solely  as  a  function  of  B(s)  and  e,  not  by 
searching  through  s’  for  point  cards.  This  refinement  was  omitted  from  DTRIV2  because  roo  lacks 
an  explicit  way  to  describe  data  structures  (§8.1.5). 

3.4.3. 1  Refined  Formulation  of  the  Search 


After  the  refinements  performed  by  f:00,  the  1  ISM  schema  has  been  instantiated  as  follows: 

( HSM 1  WITH  * 

(VARIABLES  :  (SUIT-LED2  MY-CARD4) ) 

(BINDINGS  :  ((SUIT-LED)  (CARD-OF  ME))) 

(INITIAL-PATH  :  (PROJECT  CARD-OF  (PREFIX  (PLAYERS)  ME)))) 

(CHOICE-SETS  : 

(LAMBDA  (PI)  ’ 

(SET-OF  C2  (CARDS) 

(POSSIBLE 

(ANO  [HAS  PI  C 2 ] 

:  (=>  (OUT  C2 ) 

IF  (IN  PI  (OPPONENTS  ME))) 

;  (=>  (NON-VOID  PI)  * 

IF  (IN-SUIT  C2  (SUIT-LED))) 

[=>  (LEADING  PI) 

(OR  [CAN-LEAD-HEARTS  PI] 

[NEQ  (SUIT-OF  C2 )  H])] 

[=>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)] 

[IN-SUIT  C2  (SUIT-LED)])])))))  I 

(STEP-ORDER  : 

(LAMBDA  (PI  C21 ) 

(OR  [HAVE-POINTS  CAROS  -  PLAYED  I ]  [HAS-POINTS  C2  1  ] ) ) ) 

(STEP-TEST  : 

(LAMBDA  (PI  C2 1 ) 

(=>  [NOT  (AFTER  ME  PI)]  * 

[AND  [=  (SUIT-OF  MY-CARD4 )  SUIT-LE02] 

[  =  >  [=  (SUIT-OF  C 2 1 )  SUIT-LE02] 

[NOT  (HIGHER  C2 1  MY-CAR04 )]]])) ) 
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(PATH-ORDER  : 

(LAMBDA  (CAR0S-PLAYE01)  (HAVE-POINTS  CARDS -PLAYED  1 )) ) 

(PATH-TEST  : 

(LAMBDA  (CARDS-PLAYED1) 

(=>  [IN  ME  (INOICES-OF  CARDS- PLAYED1 ) ] 

[»  (CARDS-PLAYEOl  ME) 

(HIGHEST- IN-SLIT-LED  CAROS  -  PLAYED  1 ) ] ) ) ) 

(COMPLETION-TEST  : 

(LAMBDA  (PATH)  (-  (#  PATH)  (»  (PLAYERS))))) 

(SOLUTION-TEST  : 

(LAMBDA  (CARDS-PLAYED1) 

(AND  [HAVE-POINTS  CARDS-PLAYEOl] 

[  =  (CARDS-Pl.AYEDl  ME) 

(HIGHEST- IN-SUIT-LED  CARDS-PLAYEOl)]))) 

The  search  thereby  specified  is  represented  as  a  data-flow  graph  in  Figure  3-4.  and  has  the 
following  features. 

The  object  of  the  search  is  t  find  a  sequence  of  cards.  CARDS-PLAYED1.  indexed  by  the  sequence 
of  players,  that  satisfies  die  solution-test  and  completion-test.  The  solution-test  requires  diat  the 
sequence  contain  one  or  more  point  cards  and  that  the  highest  card  in  die  suit  led  be  player  ME  s  card. 
The  completion-test  requires  diat  the  sequence  contain  one  card  for  each  player.  I  lie  combined  effect 
is  to  specify  a  sequence  of  cards  that  will  cause  play  er  me  to  take  points. 

The  choice  set  at  each  point  in  die  search,  indexed  by  player  variable  Pi,  consists  of  those  cards 
that  might  possibly  be  legal  for  PI  to  play,  Le..  whose  legality  for  Pi  is  not  contradicted  by 
information  available  to  player  me.  For  example,  in  order  for  a  card  C2  to  be  legal  for  Pi,  Pi  must 
have  C2.  If  the  truth  value  of  (HAS  pi  C2)  doesn't  happen  to  be  known  at  search  time,  player  ME 
can  check  a  couple  of  necessary  conditions.  1  lie  first  is  that  C2  be  out  it  Pi  is  an  opponent  of  ME,  in 
particular,  C2  cannot  already  have  been  played.  This  prevents  consideration  of  scenarios  in  which  the 
same  card  is  played  more  dian  once,  or  in  which  a  card  previously  taken  miraculously  reappears.  The 
see. -id  necessary  condition  is  that  Pi  be  non-void  in  the  suit  led  if  C2  is  in  the  suit  led.  A  more 
general  test  would  check  diat  PI  is  not  known  to  be  void  in  (SUIT -OF  C2). 

The  search  conservatively  takes  as  die  choice  set  all  cards  satisfying  die  known  necessary 
conditions;  dius  an  effective  wav  to  reduce  die  branching  factor  of  the  search  would  be  to  derive 
additional  necessary  conditions.  For  example,  a  diird  necessary  condition  would  be  (VOID  Pl) 
when  ( IN-SUIT  C2  (SUIT-LED));  this  would  be  of  little  help,  however,  without  some  non-trivial 
necessary  conditions  on  VOID.  Obvious  methods  for  evaluating  VOID  typically  give  sufficient  radier 
than  necessary  conditions;  it's  hard  to  be  sure  that  an  opponent  is  non-void. 
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The  search  uses  lambda  variables  SUIT-LE02  and  MY-CAR04,  which  can  be  bound  to  values 
computed  or  selected  at  the  outset  of  the  search. 

The  search  proceeds  by  choosing  a  path  from  the  search  space,  extending  it  by  one  element,  testing 
the  result  to  see  if  it’s  a  solution,  and  deciding  whether  to  add  it  to  the  search  space.  Initially  the  only 
path  in  the  search  space  consists  of  the  cards  played  by  player  mb’s  predecessors,  plus  MY-CARD4,  the 
card  being  considered  for  (CARD-OF  ME). 

'fhe  path-order  is  used  to  constrain  the  order  in  which  paths  arc  selected  for  consideration,  so  that 
paths  in  which  points  have  been  Dlaycd  arc  considered  first. 

The  step-test  is  used  to  test  possible  extensions,  so  that  paths  in  which  player  ME  doesn’t  win  the 
trick  arc  not  even  considered. 

The  step-order  is  used  to  order  possible  extensions,  so  that  point  cards  are  considered  first  when 
extending  a  path  in  which  no  points  have  yet  been  played. 

The  path-test  prunes  paths  in  which  player  ME  can’t  take  the  trick  no  matter  what  cards  arc  played 
in  the  rest  of  the  trick.  Since  the  step-test  prevents  the  generation  of  such  paths,  the  path- test  need 
not  really  be  applied  to  any  paths  other  than  the  initial-path.  RLLF323  could  be  fixed  to  reflect  this 
by  adding  an  initial-test  component  to  the  HSM  schema,  but  the  major  benefit  of  moving  constraints 
earlier  in  the  search  comes  from  combinatorial!)  reducing  the  size  of  the  search;  thus  the  constant- 
factor  cost  of  a  redundant  test  should  be  negligible  compared  to  the  unconstrained  search  executed  in 
the  absence  of  a  step- test. 

1  have  not  implemented  the  search  process  itself  beyond  describing  it,  but  it  seems  straightforward 
enough.  It  would  require  some  clean-up.  eg.,  rewriting  (Card-OF  ME)  and  (CARDS-PLAYEDl  ME) 
as  my -card  4  throughout  the  instantiated  schema.  The  need  for  such  global  substitutions  comes  from 
waiting  until  the  method  is  already  half-instantiated  before  applying  high-level  transformations,  eg., 
deciding  to  start  the  search  after  (CARD-OF  ME)  instead  of  at  die  beginning  of  the  trick.  1  wriggled 
out  of  this  by  adding  an  initial-path  component,  but  in  general  one  would  expect  such  major 
decisions  to  require  redoing  a  lot  of  the  work  done  up  to  that  point,  or  at  least  fixing  it  up. 

Finally,  the  instantiated  search  is  designed  to  be  executed  in  the  environment  used  for  evaluating 
expressions.  This  environment  provides  things  like  3-valucd  logic  (unevaluable  expressions  return  a 
value  unknown  rather  than  causing  runtime  errors),  a  state  model  (in  which  actions  can  be  simulated). 
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historical  reference  (e.g.,  the  WAS-DURING  construct),  and  multiple  evaluation  methods  (annotations). 
Such  features  seem  reasonably  straightforward  to  build  into  an  evaluator  (if  one  doesn’t  care  about 
efficiency),  but  it  would  take  a  fair  amount  of  work  and  1  haven’t  done  it.  Instead,  I've  satisfied 
myself  with  giving  specifications  for  such  an  evaluator  and  showing  how  particular  features  in  the 
evaluator  (e.g.,  annotations)  can  simplify  die  solution  of  particular  kinds  of  operationalization 
problems  (e.g.,  somctimcs-cvaluable  expressions).  None  of  these  features  is  particularly  original  so 
far  as  I  know;  for  instance,  Balzer  has  described  a  compilable  formal  specification  language  that 
permits  historical  reference  [Balzer  79). 

3.4.4.  Moving  to  a  Smaller  Search  Space 

(§3.4.1)  described  a  way  to  reduce  the  effective  branching  factor  of  the  search  by  using  a  step-test 
to  filter  the  generation  of  alternatives  at  each  choice  point.  (In  contrast,  reducing  the  number  of 
choice  points  reduces  die  depth  of  die  search  space.)  A  more  sophisticated  refinement  method,  which 
1  have  not  implemented,  would  reduce  die  branching  factor  by  moving  die  search  to  an  abstracted 
version  of  the  original  search  space: 

To  reduce  a  search  space,  suppress  operator  details  that  arc  irrelevant  to  the  search  criterion, 
and  use  the  resulung  abstractions  in  place  of  the  original  operators  |Mostow  79a]. 

Abstractions  of  operators  have  been  constructed  and  used  to  reduce  search  in  planning  systems, 
but  die  abstraction  process  has  been  limited:  operators  have  been  abstracted  by  deleting  some  of 
their  preconditions  [Newell  60]  [S  iccrdoti  V\  or  by  ignoring  variable  bindings  [Sacerdoti  74]  [Klahr 
78].  In  contrast,  die  abstractions  proposed  below  would  be  synthesized  based  on  analysis  of  the 
search  criterion  and  knowledge  about  the  task  domain. 

For  instance,  from  the  point  of  view  of  avoiding  taking  points,  it  often  doesn't  matter  what  suit  an 
opponent  plays  (just  whether  it’s  in  die  suit  led  or  has  points),  or  exactly  how  low  an  opponent’s  card 
is  (as  long  as  it’s  lower  than  (CARD-OF  ME)).  This  suggests  reducing  die  generator  set  from  a  set  of 
cards  to  a  set  of  abstract  alternatives  like  {UMDER-PLAY,  0R0P-P0INTS,  BREAK-SUIT],  These  abstract 
alternatives  represent  equivalence  classes  of  concrete  ones,  and  the  equivalence  relation  strongly 
depends  on  the  tusk  situation.  For  instance,  in  some  eases  playing  any  heart  will  have  die  same 
impact  on  the  outcome  of  die  trick,  w  hile  in  others  the  particular  heart  played  might  determine  who 
wins  the  trick.  An  obvious  approach  to  this  problem  is  to  look  dynamically  for  "easy"  equivalences 
and  use  them  to  reduce  the  search  space  for  the  particular  situation  at  hand  according  to  die  heuristic 

Ignore  a  n  alternative  if  an  equivalent  one  has  already  been  considered. 
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Suppose  an  abstract  alternative  like  UNDER-PLAY  is  defined  as  the  set  of  all  choices  x  satisfying 
P(x).  Then 

1.  Look  for  sufficient  conditions  S(x,  x’)  for  (P(x)  <  =  >  P(x')). 

2.  Partition  the  generator  set  into  equivalence  classes  Cx  =  {x’  |  S(x,  x’)}. 

3.  Replace  the  old  generator  set  with  a  new  one  containing  a  single  representative  element  of  each 
class.  Since  the  revised  generator  produces  the  same  kind  of  elements  as  the  old  one  (rather 
than  some  kind  of  abstracted  clement),  the  other  control  components  still  work. 

4.  Perform  the  search  as  usual. 

A  similar  approach  is  to 

Ignore  an  alternative  if  a  better  one  has  already  been  considered. 

This  approach  is  based  on  the  concept  of  extreme  cases  [Lenat  7SJ: 

1.  Find  a  sufficient  condition  Bctter(s,  s')  (“s  dominates  s’”)  such  that  if  s'  can  be  extended  into  a 
solution  then  so  can  s.  'flic  predicate  Betters,  s')  can  be  used  to  order  paths  by  considering  s 
before  s'  if  s  dominates  s’. 

2.  Use  a  path-test  Best(s)  =  ~3s’  |  Betters’,  s)  reflecting  the  fact  that  if  an  “easiest  case"  s  fails,  so 
will  every  path  s’  known  to  be  harder  than  it. 

3.  Use  a  step-test  Bcst(s  &  c),  where  s  represents  the  sequence  of  choices  made  before  c. 

A  disadvantage  of  this  approach  lies  in  having  to  repeat  the  dynamic  search  for  sufficient 
conditions  in  each  new  situation.  Nonetheless,  dais  might  capture  an  aspect  of  human  play  -  figuring 
out  what  will  happen  if  player  p  plays  card  x,  and  then  jumping  to  the  conclusion  that  the  same  tiling 
will  happen  if  p  plays  any  other  card  in  the  class  Cx.  The  major  obstacle  in  implementing  this 
approach,  of  course,  would  be  to  mechanize  the  analysis  involved  in  identifying  evaluable  sufficient 
conditions  for  equivalence  or  domination. 

3.4.5.  Refining  HSM:  Summary 

FOO's  HSM  refinement  rules  transfer  constraints  from  one  component  of  die  HSM  schema  to 
another,  as  shown  in  Figure  3-5.  Some  rules  prune  search  paths  that  can't  lead  to  a  solution.  Other 
rules  re-order  the  search  to  consider  the  most  promising  paths  first.  F.  wily,  some  rules  compile 
constraints  out  of  the  search  altogether.  In  general,  die  rules  transfer  constraints  so  as  to  apply  diem 
earlier  in  the  search,  as  shown  in  Figure  3-6. 
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3.5.  Another  Example:  Compose  a  Cantus 


So  far  poo  r  HSM  schema  and  to  rules  for  instantiating  and  refining  tins  schema  hare  been 
illustrated  sold,  in  terms  of  die  '.void  taking  points"  example.  As  a  test  of  generaht,.  1  applied  dte 
same  rules  to  a  task  from  die  domain  of  music:  "compose  a  cantos  firmos."  A  crrrtrus  yi™«s  »  • 
science  of  musical  tones  of  coal  length  satisfying  certain  amdi.de  constraints,  and  forms  the 

melodic  backbone  of  a  piece  of  music. 

A  program  to  generate  such  sequences  was  implemented  b,  Meehan  (Meehan  7:]  using  aesthetic 
constraints  given  in  a  textbook  on  counterpoint  ISalxer  691.  Meehan  structured  Ms  program  as  , 
depth-first  'search  through  die  space  of  tone  sequences,  and  used  die  cent,  or  so  textbook 
constraints  to  prune  the  search.  Meehan  has  said  that  this  approach  "isn't  how  music  is  or  should  c 
.ritten  an,  more  dtan  a  recursive  enumeration  of  all  die  legal  strings  of  some  nice  grammar  .or, 
describe  die  generation  of  natural  language:"’  [Meehan  79).  he  proposes  an  Al  approach  to  music 
composition.  Although  this  constraint  satisfaction  problem  mav  be  considered  irrelevant  to  rc 
music,  i,  provides  a  well-defined  syinboiie  task  suitable  as  a  vehicle  for  evaluating  die  genera,,,,  of 

FOO's  knowledge  about  HSM. 


For  my  experiment.  I  took  four  constraints  from  [Salz.cr  69]: 

Cl  “As  a  rule  the  cantus  will  not  contain  fewer  than  eight  or  more  than  sixteen  tones." 

C2.  “The  cantus  firmus  should  not  contain  intervals  larger  than  an  octave,  dissonant  leaps,  or 
chromatic  half  steps. 

C3  “A  tenth  between  the  lowest  and  the  highest  tone  is  the  maximum  range. 

C4,  "bach  cantus  Onto,  must  contain  a  climax  or  high  point....  The  climax  tone  should  nut  be 
repeated.” 


1  encoded  these  constraints  in  FOO  ar  follows: 

Cl:  (IN  (LENGTH  (CANTUS))  (LB:UB  3  16)) 

c 2 :  (FORALl  X  ( INTERVALS-OF  (CANTUS))  (USABLE- INTERVAL  X)) 
03:  (=<  (MELODIC-RANGE  (CANTUS))  (MAJOR  10)) 

04 :  (=  (^OCCURRENCES  (CLIMAX  (CANTUS))  (CANTUS))  1) 


The  goal  of  the  experiment  was  to  operationalize 


these  constraints  mechanically  in  terms  of  HSM 


7\ieehan.  personal  communication. 
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using  the  same  rules  used  in  the  "avoid  taking  points”  example,  or  similar  ones.  The  task  of 
composing  a  cantus  firmus  was  represented  as 

(ACHIEVE  (LEGAL-CANTUS  (CANTUS))) 

Here  the  predicate  LEGAL-CANTUS  tests  whether  a  given  tone  sequence  satisfies  C1-C4,  and 
CANTUS  denotes  the  act  of  composing  a  cantus  by  choosing  each  note  in  succession: 

(CANTUS)  =  (EACH  I  (LS:UB  I  ( CANTUS -LENGTH ) )  (CHOOSE-NQTE  I)) 

'Hie  term  ( CANTUS-LENGTH)  is  undefined;  it  appears  because  roo  lacks  a  construct  for  defining  a 
cantus  as  a  sequence  of  unspecified  length  -  a  beast  more  type-like  than  object-like,  in  that  it  describes 
a  class  of  possible  objects.  Such  an  entity  could  be  defined  intensionally  by  a  predicate  like 

(IS-CANTUS  S)  =  (FORALL  I  ( LB : UB  1  (LENGTH  S)) 

( IS-CHOOSE -NOT E  I  (S  I))) 

"A  cantus  is  a  sequence  of  events  the  iLh  of  which  consists  of  choosing  die  1th  note.” 

However.  1  wanted  (CANTUS)  to  denote  die  cantus  itself,  not  a  truth  value.  DER.IV14  circumvents 
this  problem  by  using  the  variable  CANTUS  to  denote  the  cantus,  with  the  implicit  assumption  that 
cantus  satistles  the  predicate  IS -Cantus. 

The  rest  of  this  section  parallels  the  description  of  die  "avoid  taking  points"  example  in  (§3.3) 
through  (§3.4.3. 1).  (§3.5.1)  describes  the  process  of  instantiating  the  HSM  schema  for  the 
composition  task.  (§3.5.2)  presents  the  initial  instantiation.  (§3.5.3)  describes  a  series  of  subsequent 
refinements  to  the  search  and  die  general  rules  used  to  make  diem.  (§3.5.4)  describes  die  refined 
search.  Both  the  initial  formulation  and  the  subsequent  refinement  of  die  search  involve  several 
HSM  rules  used  in  die  Hearts  example  as  well.  (§3.5.5)  presents  further  evidence  for  the  generality  of 
these  ailes  by  showing  how  they  could  be  used  to  make  additional  refinements  in  the  music  example. 


3.5.1.  Formulating  the  Search 

The  first  step  in  mapping  the  problem  (ACh:c,'E  (LEGAL-CANTUS  (CANTUS)))  onto  die  HSM 
schema  is  to  recognize  the  relevance  of  HSM  to  die  problem.  This  is  effected  by  the  same  mlc  that 
recognizes  "avoid  taking  points"  as  a  heuristic  search  problem: 
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RLLF306:  (P...e...) 

->  (HSM  with  (problem  :  (P  ...  e  ...»  --  expression  to  be  evaluated 
(object :  e)  --  scenario  containing  choices 

(choice-seq  :  (choice-seq-of  e»)  --  sequence  of  choices  made  in  scenario 
if  e  contains  an  event  sequence  involving  choice 

Use  heuristic  search  to  evaluate  a  predicate  on  a  scenario  in  which  choices  are  made. 


Thus  DHRIV13.  die  derivation  for  the  "compose  a  cantus  tirmiis"  example,  begins  as  follows: 

(LEGAL-CANTUS  (CANT'JS)) 

13:1  ---  [by  RULE306]  ---> 

HSM1 

(HSM1  <-  PROBLEM  :  ( LEGAL-CANTUS  (CANTUS))) 

( HSM 1  <-  OBJECT  :  (CANTUS)) 

( HSM1  <-  CHOICE-SEQ  :  (CHO ICE -S EQ-OF  (CANTUS))) 


In  this  case  the  predicate  P  is  LEGAL-CANTUS  and  the  object  e  is  the  event  sequence 
(CANTUS)  =  (EACH  I  (L3:UB  1  ( CANTUS  -  LENGTH ) )  ( CHOOSE -NOTE  I)) 


This  scenario  involves  the  choice  event 

(CHGOSE-NOTE  (NOTE  I)  (TONES)  (NOTE  I)) 


As  before,  the  next  step  is  to  identify  the  sequence  of  choices  involved.  Inc  same  rules  are  used. 

(Unless  otherwise  noted,  the  HSM  rules  used  below  are  die  same  ones  developed  for  the  “avoid 

taking  points"  example,  although  the  analysis  required  is  different.) 

(CHOICE -SEQ-OF  (CANTUS)) 

13:2-8  ---  [by  RULE307-309,  analysis]  ---> 

(EACH  II  ( LB  :  U8  1  ( CANTUS  -  LENGTH ) ) 

(CHOOSE  (NOTE  II)  (TONES)  (NOTE  II))) 


This  enables  several  components  of  the  HSM  schema  to  be  instantiated: 

13:9  ---  [ELABORATE  by  RULE311]  ---> 

( HSM l  <-  SEQUENCE  :  NOTE) 

( HSM1  <-  CHOICES  ;  (PROJECT  MOTE  (L8:UB  1  (CANTUS-LENGTH )  )  )  ) 
(KSM1  <-  CHOICE-SETS  :  (LAMBDA  (II)  (TONES))) 

( HSM1  <-  INDICES  :  (L8:UB  1  (CANTUS-LENGTH))) 

(HSM1  <-  INDEX  :  II) 

( HSM  1  <-  VARIABLES  :  NIL) 

(HSM1  <-  BINDINGS  :  NIL) 

( HSM 1  <-  INITIAL-PATH  :  NIL) 

(HSM1  <-  COMPLETION-TEST  : 

(LAMBOA  (PATH) 

(-  (LENGTH  PATH)  (LENGTH  (L3:U8  1  (CANTUS-LENGTH)))))) 


For  example,  the  choice  set  for  the  I  lth  note  in  the  cantus  is  specified  to  be  die  entire  set  of 
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(TONES )  available,  and  is  thus  independent  of  1 1.  (However,  a  subsequent  refinement  narrows  the 
choice  set  at  each  point  in  a  way  that  depends  on  the  previous  note.) 


The  search  criterion  can  now  be  reformulated  in  terms  of  die  identified  choice  sequence.  The  the 

solution-test  is  extracted  from  the  resulting  expression,  and  some  defaults  arc  filled  in: 

(REFORMULATE  ( LEGAL-CANTUS  (CANTUS)) 

(PROJECT  NOTE  (LB:UB  1  ( CANTUS  -  LENGTH ))) ) 

13:10-18  ---  [by  RULE315,  RULE317 ,  analysis]  ---> 

( HSM1  <-  SOLUTION-TEST  : 

(LAMBDA  ( PROJECT  1 ) 

(AND 

Cl:  [IN  (LENGTH  PROJECT!)  (LB:UB  8  16)] 

C2 :  [FORALL  INTERVAL  1  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL  IMTERVAL1 )  ] 

C3 :  [  =  <  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)] 

C4 :  [=  ( /^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  1]))) 

(HSM1  <-  PATH-TEST  :  T ) 

( HSM1  <-  PATH-ORDER  :  NIL) 

( HSM 1  <-  STEP-TEST  :  T) 

( HSM1  <-  STEP-ORDER  :  NIL) 

( HSM  1  <-  PATH  :  PROJECTl) 


So  far  instantiation  of  die  HSM  schema  for  the  cantus  example  has  paralleled  the  initial  phase  of 
die  “avoid  taking  points"  example.  At  this  point  it  diverges  in  order  to  fix  up  die  completion-test 
(LAMBDA  (PATH) 

(-  (LENGTH  PATH)  (LENGTH  ( LB :UB  1  ( CANTUS -LENGTH )))) ) 


This  test  is  noil-operational  since  CANTUS-LENGTH  is  undefined.  Fortunately  constraint  Cl  gives  a 
criterion  for  identifying  complete  paths,  so  it  is  moved  from  the  solution-test  to  die  completion-test: 
13:  19  ---  [by  RULE3  78]  ---> 

( HSM 1  <-  COMPLETION-TEST  : 

(LAMBDA  (PROJECTl)  (IN  (LENGTH  PROJECTl)  ( LB : UB  3  16)))) 

(HSM1  <-  SOLUTION-TEST  : 

(LAMBDA  (PROJECTl) 

(AND  [FORALL  INTERVAL1  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL  INTERVAL1 ) ] 

[=<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)] 

[*  (/^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  1]))) 


This  correction  is  made  by  a  rule  not  used  in  the  "avoid  taking  points"  example: 

RLf.F3"3:  (HSM  with  (soiution-test :  (lambda  (s)  (and  ...  (P  (lengdi  s)) ...)))) 

->  (HSM  with  (completion-test :  (lambda  (s)  (P  (length  s)))) 

(solution-test :  (lambda  (s)  (and  ...)))) 

assuming  die  previous  completion-test  was  undefined  or  subsumed  by  the  new  one 
Jf  the  soiution- lest  contains  a  constraint  on  path  length,  move  :t  to  the  completion-  test. 
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The  idea  ot'this  rule  is  that  a  test  that  depends  solely  on  die  length  of' a  path  is  a  halting  criterion 
and  therefore  belongs  in  the  completion-test.  Actually,  this  step  would  be  unnecessary  if  the 
representation  allowed  (CAMTUS-LENGTH)  to  be  defined  as  "any  non-negati\e  integer",  so  dial  the 
original  completion-test  would  reduce  to  T: 

(LAMBDA  (PATH) 

(  =  (LENGTH  PATH)  (LENGTH  (LB:U8  1  ( CANTUS - L E NGTH )))) ) 

—  [by  definition  of  L8:U8]  — > 

(LAMBDA  (PATH)  (=  (LENGTH  PATH)  ( CANTUS-L E NGTH ) ) ) 

---  [by  definition  of  CANTUS-LENGTH]  ---> 

(LAM80A  (PATH)  (-  (LENGTH  PATH)  < non- nega t i ve  integers)) 

—  [by  definition  of  <non-negative  integers]  - > 

(LAMBDA  (PATH)  (>=  (LENGTH  PATH)  0)) 

—  [by  definition  of  LENGTH]  - > 

(LAMBDA  (PATH)  T) 

1  lie  problem  with  this  is  the  implicit  ambiguous  quantification  in  the  expression 

(-  (LENGTH  PATH)  <non  -  nega t i ve  integer!) 

The  intended  meaning  of  this  expression  is 

(EXISTS  I  (NON-NEGATIVE-INTEGERS)  (*  (LENGTH  PATH)  I)) 

Howe\ er,  the  syntax  of  the  first  expression  fails  to  specify  the  scope  of  die  quantifier  EXISTS.  For 
example,  if  (*  (LENGTH  path)  <non-negative  integer!)  occurred  as  part  of  a  larger  boolean 
expression,  would  the  quantifier  apply  to  the  sub-expression  or  to  the  whole  thing?  The 
quantification  issue  in  knowledge  representation  has  been  discussed  elsewhere,  e.g..  in  [Woods  75|. 

3.5.2.  Initial  Formulation  of  the  Search 


The  components  of  die  HSM  schema  have  now  been  instantiated  as  follows: 
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( HSM 1  WITH 

( INITIAL-PATH  :  MIL)) 

(CHOICE-SETS  :  ( LAM80A  (It)  (TONES)))) 

(STEP-ORDER  :  NIL) 

(STEP-TEST  :  T) 

(PATH-OROER  :  NIL) 

(PATH-TEST  :  T) 

(COMPLETION-TEST  : 

Cl:  (LAMBDA  (PROOECT1)  (IN  (LENGTH  PROJECT1)  ( LB :  UB  8  16)))) 

(SOLUTION-TEST  : 

( LAM80A  ( PROJECT  1 ) 

C2 :  (AND  [FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USA8LE-INTERVAL  INTERVALl )  ] 

C3 :  [=<  ( MELOO IC-RANGE  PROJECTl)  (MAJOR  10)] 

C4 :  [•  ( ^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  1])))) 


The  search  thereby  specified  corresponds  to  the  generate-;: nd-test  procedure  shown  in  Figure  3-7. 
Although  executable  in  theory,  it  would  prove  combinatorially  inefficient  in  practice,  since  the 
constraints  CI-C4  are  not  used  to  constrain  the  search. 


3.5.3.  Refining  (he  Search 

The  refinement  rules  introduced  in  the  "avoid  taking  points"  example,  and  others  like  them,  can 
now  be  used  to  move  constraints  earlier  in  the  search.  This  section  discusses  the  constraints  C2,  C3, 
and  C4  in  turn.  (Recall  that  Cl  has  already  been  moved  from  solution-test  to  completion-test.) 

3.5.3.1  Moving  C2  to  the  step-test 

The  constraint  C2  appears  in  the  solution-test  as  the  clause 

(FORALL  INTERVAL  1  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL  INTERVALl ) ) 


(t  is  moved  to  the  path-test  by 

RUI.E323:  If  the  solution-test  includes  <tn  faintest)  tnonrtonically  necessary  constraint  P 
Then  determine  the  condition  \l  under  which  P  is  monotoiucnlly  necessary. 

And  add  (  ~>  M  P)  to  the  path- test. 


Here  the  monotonicity  condition  M  reduces  to  T.  yielding 

13:20-27  —  [by  RULE323 ,  analysis]  ---> 

( HSM  1  <-  PATH-TEST  ; 

(LAMBOA  (PROJECTl) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 
(USABLE-INTERVAL  INTERVALl)))) 
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INITIAL 

PATH 

nil 


CHOICE 

SET 


set  of  tones 


Figure  3*7:  Initial  Search  for  Compose  Cantus 
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Constraint  C2  is  then  moved  to  die  step-test  by 

RULE327:  If  the  path-test  includes  a  constraint  Ps, 

And  Ps  is  equivalent  to  (fora! I  i  (indices- of  s)  Qs ^  for  some  predicate  Q, 
Then  add  the  constraint  Qc  to  the  step- test. 


This  involves  a  change  of  variable  so  as  to  quantify  over  notes  instead  of  intervals.  The 

requantified  constraint  specifics  that  each  note  is  a  usable  interval  away  from  its  predecessor: 

13:28-43  ---  [by  RULE327 ,  analysis]  ---> 

( HSM1  <-  STEP-TEST  : 

(LAMBDA  (II  NOTE  1 ) 

(OR  [USABLE-INTERVAL  (INTERVAL  (PR0JECT1  (-  II  1))  NOTE  1 ) ] 

[=  II  1]))) 


The  exception  for  II  =  1  indicates  that  this  constraint  does  not  apply  to  the  generation  of  the  first 
note  of  the  cantus,  since  that  note  has  no  predecessors  with  which  to  form  an  interval.  The  effect  of 
moving  C2  to  the  step-test  is  to  prevent  die  extension  of  paths  by  intervals  diat  fail  to  satisfy  the 
USABLE- interval  predicate. 


3.5.3.2  Precomputing  C2 


A  further  improvement  is  achieved  by  constraining  die  next-note  generator  to  satisfy  C2  to  begin 

with.  First  C2  is  moved  into  the  definition  of  die  choice  set: 

13:52  ---  [REFINE  by  RULE384]  ---> 

(HSM1  <-  CHOICE-SETS  : 

(LAMBDA  (II) 

(SET-OF  NOTE  1  (TONES) 

(OR  [USABLE-INTERVAL 

(INTERVAL  ( PROJECT  1  (-  II  I))  MOT E 1 ) ] 

C*  H  l])))) 

(HSM1  <-  STEP-TEST  :  T) 


♦ 


This  is  accomplished  by  a  new  rule  (i.e..  one  not  used  in  the  Hearts  example): 

RL'LF334:  (HSM  with  (step-test :  (lambda  (i  c)  Pic)) 

(choice-sets  :  (lambda  (i)  Si))) 

->  (HSM  with  (step-test :  T) 

(choice-sets :  (lambda  (i)  (set-ofc  Si  Pic)))) 

If  the  step-test  includes  a  constraint  P, 

Change  the  choice  set  S  to  be  {x  in  S/  Px}. 


I  This  transformation  by  itself  doesn't  improve  the  efficiency  of  the  search,  since  it  merely  moves  the 

^  I  gencratc-and-test  cycle  into  the  evaluation  of  CHOICE-SETS.  In  this  instance,  however,  the  test  can 

be  moved  out  of  the  search  altogether  by  precomputing  the  function 

►  > 

L 
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USABLE-SUCCESSQRS-OF  = 

(LAM80A  ( NOTE  1 ) 

(SET-OF  NOTE2  (TONES) 

(USABLE-INTERVAL  (INTERVAL  NOTE!  NOTE2 ) ) ) ) 


The  function  USABLE-SUCCESSORS-OF  is  prccomputabic  since  it  depends  only  on  the  last  note, 

NOTE1,  of  the  path  PROJECT  1.  I  f  the  set  ( TONES)  is  reasonably  small,  it  is  feasible  to  precompute  and 

store  in  a  table  the  usable  successors  of  each  tone.  The  generator  can  then  be  revised  to  retrieve  the 

usable  successors  of  the  last  note: 

13:53-56  —  [by  RULE386,  analysis]  - > 

( HSM1  <-  CHOICE-SETS  : 

(LAMBDA  (II) 

(IF  (-  II  1) 

(TONES) 

(USABLE-SUCCESSORS-OF  (PROJECTl  (-  II  1)))))) 


The  fiinction  USABLE-SUCCESSORS-OF  was  synthesized  by  l  00.  (I  provided  a  name  for  the 
function  when  asked  by  t  oo  to  do  so.)  The  general  rule  for  precomputing  the  choice  set  is 

RUI.F.386:  (HSM  with  (path :  s) 

(choice-sets  :  (...  (set-of  x  S  (P  ...  (g  s) ...)) ...))) 

->  (HSM  with  (choice-sets  :  (f  (g  s))» 
f  <-  (lambda  (y)  (set-of  x  S  (P  ...  y  ...))) 
if  (P  ...)  is  otherwise  independent  of  s 

If  the  choice  set  has  the  form  {x  in  S  |  P(x.  g(s))[ 

[Where  S  and  range(g)  are  small 

And  P  doesn't  otherwise  depend  on  the  path  variable  s.j 

Then  define  a  new  function  l]y)  =  {x  in  S  |  P(x,  y)} 

And  change  the  choice  set  to  tlg(s)). 

Where  f  is  precomputed  and  stored  in  a  table  before  die  search  begins. 


As  implemented.  1 00  does  not  test  the  bracketed  clauses  of  RUI.H3S6.  Here  S  =  (TONES)  and  g 
=  (PROOFCT1  (-  II  l)).  The  size  of  ( TOMES)  could  be  determined  by  counting  it.  given  an 
extension;.;!  definition,  or  by  asking  the  user.  The  fact  that  the  range  of  PROJECT  I  (considered  as  a 
function  from  integers  to  notes)  is  a  subset  of  (TONES)  could  be  determined  by  analysis.  The  space 
cost  of  storing  f  in  a  table,  say  as  an  array  of  lists  of  tones,  is  easy  to  predict  given  the  average 
frequency  with  which  the  predicate  USABLE-INTERVAL!  is  satisfied.  Computations  of  a  similar  sort 
have  been  performed  by  systems  that  evaluate  alternative  data  structures  for  a  given 
application  [Kant  79]  [Low  "’SJ. 


A  potentially  difficult  aspect  of  RULF386  is  to  verify  that  P  does  not  depend  implicitly  on  s.  An 
intersection  search  could  be  used  to  determine  whether  any  of  the  concepts  in  P  mentioned  s  in  their 
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definitions,  but  the  approacli  would  have  to  be  refined  to  account  for  an  aliasing  problem:  the 
sequence  might  be  referred  to  by  a  name  other  than  PROJECT  l,  c.g.,  (CANTUS)  or  (NOTE  II). 

Note  that  constraint  C2.  originally  part  of  tire  solution-test,  has  now  been  factored  out  of  the  search 
altogether.  Instead  of  considering  the  entire  set  of  (TONES)  when  extending  a  path  (tone  sequence), 
the  search  will  only  consider  the  legal  successor  tones  of  the  last  note.  The  effect  of  this  refinement  is 
to  reduce  the  branching  factor  of  die  search. 

3.5.3.3  Moving  C3  to  the  Path-test 

Constraint  C3  appears  in  tire  solution-test  as 

(=<  (MELODIC-RANGE  PR0JECT1)  (MAJOR  10)) 

C3  is  moved  from  the  solution-test  to  the  path-test  by  the  same  rule  used  previously: 

13:44-51  ---  [by  RULE323 ,  analysis]  ---> 

(HSM1  <-  PATH-TEST  : 

(AND  ...  [LAMBDA  (PROJECTl) 

(=<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10))])) 

The  effect  of  this  refinement  is  to  prune  paths  as  soon  as  their  range  exceeds  the  allowable  limit  of 
a  major  tenth,  thereby  preventing  the  consideration  of  their  various  extensions. 

In  principle,  RULE327  could  be  used  to  reformulate  the  path-test  version  ofC3  as  the  step-test 

(AND  [  =  <  (SIZE  (INTERVAL  (LOWEST  PROJECTl)  NOTE  1 ) )  (MAJOR  10)] 

[=<  (SIZE  (INTERVAL  NOTE1  (HIGHEST  PROJECTl))  (MAJOR  10)]) 

However,  diis  would  require  a  considerable  amount  of  analysis  based  on  the  mathematical 
properties  of  intervals,  and  l  didn't  do  it. 

3.5.3.4  Vuriahili/ing  C4 

The  constraint  C4  appears  in  die  solution-test  as 

(=  ( ^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)) 

In  this  form,  C4  cannot  be  moved  to  the  path-test  (by  RLI.E323)  or  path-order  (by  RUI.E335), 
since  it  is  neither  monotonically  necessary  nor  sufficient.  I'hat  is.  whether  or  not  the  highest  note  of  a 
partial  cantus  has  occurred  only  once  has  no  bearing  on  whether  the  completed  cantus  will  have  die 
same  pnpertv.  Part  of  die  reason  for  this  is  that  the  rwo  may  have  different  climaxes,  since  in  the 
course  of  extending  the  partial  cantus  a  higher  note  ma\  be  added  on. 
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One  way  to  simplify  this  problem  is  to  choose  a  climax  tone  before  generating  the  cantos  (§2.12). 

In  fact.  Meehan's  program  asked  the  user  to  select  a  climax  tone  [Meehan  72).  This  idea  can  be 

implemented  by  variabilizing  (CLIMAX  ( CANTUS ) ),  just  as  (SUIT-LED)  and  (CARD-OE  ME)  were 

variabilized  in  the  Hearts  example: 

(=  ( ^OCCURRENCES  (CLIMAX  PROJECT!)  PRGJECT1)  1) 

13:58  ---  [by  RULE256]  ---> 

(AND  [=  (CLIMAX  PR0JECT1)  CLIMAX!] 

[=  (^OCCURRENCES  CLIMAX1  PR0JECT1)  1]) 

;  ASSUMING  (SELECT  CLIMAX1  (TONES)) 

Here  tire  variable  CLIMAXl  denotes  a  tone  to  selected  before  the  search  begins.  This  permits 
constraint  C4  to  be  split  into  two  sub-goals.  The  first  sub-goal  (call  it  C4a)  is  to  ensure  that  CLIMAXl 
is  the  climax  of  die  generated  cantos  (i.e..  that  no  other  note  is  higher).  The  second  sub-goal  (C4b)  is 
to  make  sure  that  CLIMAXl  occurs  exactly  once  in  the  cantus,  i.c..  is  not  repeated.  The  idea  of 
restricting  a  problem  by  determining  one  of  its  features  a  priori  is  expressed  by 

RUI.H256:  (P ...  (f s) ...)  ->  (and  [=  (f s)c]  [P  ...  c  ...j) 

where  e  is  to  be  selected  from  (range  0  before  s  is  constructed 

To  construct  an  object  s  so  as  to  satisfy  a  constraint  P(s.  ;{s)). 

Chouse  a  value  cj'or  j(s). 

And  solve  the  two  subproblems  P(s,  c)  andj(s)=c. 

This  strategy  may  or  may  not  succeed,  depending  on  the  choice  of  c.  For  example,  if  Cl  IMAX  l  is 
chosen  to  be  the  lowest  tone  in  (TONES),  it  will  be  impossible  to  construct  a  legal  cantus. 
Backtracking  offers  one  way  around  this  problem:  if  the  search  peters  out  or  continues  too  long 
without  finding  a  solution,  pick  another  value  for  c  and  start  over.  A  more  sophisticated  approach 
would  be  to  identify  necessary  conditions  on  the  satisfiability  of  P  and  choose  c  accordingly.  This 
approach  would  avoid  choosing  the  lowest  tone  in  (TONES)  for  CLIMAXl  because  its  only  legal 
successor  would  be  a  higher  note.  Whether  the  detailed  analysis  required  by  this  approach  would  be 
woidnvhite  would  depend  on  empirical  characteristics  of  the  search  space:  it  might  '.veil  be  more 
efficient  to  choose  CLIMAXl  randomly  from  the  entire  set  of  (TONES)  and  backtrack  when  necessary. 
Another  approach  is  to  leave  the  selection  of  such  parameters  to  the  user,  who  may  know  which 
choices  are  likely  to  work. 

An  alternative  is  to  follow  a  strategy  something  like  this  one.  derived  in  OFRIV14  (§2.1  ’.): 

If  tire  highest  note  so  far  occurs  only  once,  try  not  to  repeat  it. 

Otherwise,  try  to  add  a  higher  note. 


« 
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Here  the  importance  of  ''trying”  to  satisfy  a  goal  increases  as  the  deadline  imposed  by  the  end  of 
the  cantus  approaches.  However,  it  is  not  clear  how  to  represent  the  importance  of  a  goal,  since  !  00 
lacks  a  way  to  refer  to  the  set  of  goals  being  pursued  at  a  given  time  (§8.2.3)  --  a  consequence  of  my 
decision  to  consider  only  pieces  of  advice  that  can  be  operationalized  independently  of  each 
other  (§1.1.2). 

3.S.3.5  Splitting  C4a  and  Moving  it  to  the  Step-test 

To  move  constraint  C4a  earlier  in  the  search,  it  is  first  split  into  a  conjunction: 

(  =  (CLIMAX  PROJECT  1 )  CLIMAX1) 

13:1-63  —  [by  analysis]  — > 

(AND  [IN  CLIMAX1  PR0JECT1] 

[FORALL  XI  PROJECT!  (NOT  (HIGHER  XI  CLIMAX1))]) 


The  second  conjunct  is  a  necessary  condition  of  die  kind  discussed  earlier,  and  can  be  moved  from 

solution-test  to  padi-test  to  step-test: 

13:65-71  ---  [by  RULE323 ,  analysis]  ---> 

( HSM1  <-  PATH-TEST  : 

(AND  . . .  [LAMBDA  ( PROJECT  1 ) 

(FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX  1 )))]) ) 

13:72-80  ---  [by  RULE327 ,  analysis]  ---> 

( HSM1  <-  STEP-TEST  : 

(LAMBDA  (II  N0TE3)  (NOT  (HIGHER  N0TE3  CLIMAX  1 ) ) ) ) 


This  refinement  avoids  generating  paths  containing  a  note  higher  than  the  pre-selected  CLIMAX1. 


3.5.3.6  Splitting  C4b  and  Moving  it  to  the  Step-test 


Similarly,  splitting  constraint  C4b  into  a  conjunction  allows  it  to  be  moved  earlier  in  the  search: 

(=  (ft OCCURRENCES  CLIMAX1  PROJECT  1 )  1) 

13:83  —  [by  antisymmetric  property  of  >=]  - > 

(AND  [>=  ( ^OCCURRENCES  CLIMAX1  PR0JECT1)  1] 

[>=  1  ( ^OCCURRENCES  CLIMAX1  PROJECT  1)3) 

13:84-87  -  [by  analysis]  - > 

(AND  [IN  CLIMAX1  PROJECT  1J 

[  =  <  (OCCURRENCES  CLIMAX1  PROJECT  1 )  1]) 


The  second  clause  of  this  conjunction  can  be  moved  into  the  step-test  via  die  path-test: 
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13:92-104  ---  [by  RULE323 ,  analysis]  ---> 

{ HSM1  <-  PATH-TEST  : 

(AND  . . .  [LAM8DA  (PR0JECT1) 

(=<  (^OCCURRENCES  CLIMAX1  PROJECTl)  1)])) 

13:105-116  ---  [by  RULE389 ,  analysis]  ---> 

(HSM1  <-  STEP-TEST  : 

(LAMBDA  (II  N0TE3 ) 

(AND  [NOT  (HIGHER  NOTE3  CLIMAXI)] 

[OR  [NOT  (-  CL1MAX1  NOTE3)] 

[NOT  (IN  CLIMAX1  PROJECTl)]]))) 


The  effect  of  this  refinement  is  to  avoid  generating  a  path  in  which  CLIMAXI  is  repeated.  This  is 
the  same  kind  of  transfer  performed  by  RL  LF327.  but  uses  a  slightly  different  rule: 

RULE389:  (HSM  with  (patli-test :  (lambda  (s)  Rs)) 

(step-test :  (lambda  (i  e)  Ric)) 

->  (HSM  with  (step-test :  (lambda  (i  c)  (and  Ric  Qc)))) 

where  Qc  is  the  result  of  simplifying  (R  (append  s  (list  c)» 

If  the  path- test  contains  a  constraint  P  on  paths  x; ...  an. 

And  P(x t ...  x.J  is  equivalent  to  Q(x,J. 

Then  add  Q  to  the  step- test. 


Although  RU1..E389  is  not  used  in  the  '‘avoid  taking  points"  example,  it  closely  resembles  in  form 
the  rule  used  to  move  the  have-points  constraint  from  path-order  to  step-order: 

RULH338:  (HSM  with  (path-order :  (lambda  (s)  Rs))) 

->  (HSM  with  (step-order :  (lambda  (i  cl  Qc))), 

where  Qc  is  the  result  of  simplifying  (R  (append  s  (list  c))) 

If  the  path-order  contains  a  constraint  P  on  paths  x/ ... 

And  P(x[ ...  xj  is  equivalent  to  Q(xJ, 

Then  add  Q  to  the  step-order. 


The  analysis  used  to  simplify  the  step-test  version  of  constraint  C4b  includes  the  interesting  step 

(=<  ( ^OCCURRENCES  CLIMAXI  PROJECTl)  1) 

13:108  ---  [EVAL  by  RULE390 ]  ---> 

r 


This  step  is  based  on  the  inductive  argument  that  the  step-test  will  only  he  used  to  extend  paths 
that  already  satisfy  the  path-test,  so  any  property  of  PROJECTl  required  by  the  path-test  can  be 
assumed  true  in  the  step-test.  This  idea  is  expressed  in  general  as 

RULH390:  (HSM  with  (path-test :  (lambda  (s)  (and  ...  Ps  ...))) 

(step-test :  (...  Rs  ...))) 

->  (HSM  with  (step-test :(...  T  ...))) 


I 
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Remove  a  constraint  Ps  from  the  step- test  if  it  occurs  in  the  path- lest. 


3.5.4.  Refined  HS\1  Formulation  for  Cantus  Firmus  Example 

The  net  result  of  the  refinements  for  the  cantus  example  is  to  instantiate  the  H3M  schema  as 
follows: 


( HSMl  WITH 

( INITIAL-PATH  :  NIL) 

(CHOICE-SETS  : 

( LAM80A  (II) 

(If  (=  II  1) 

( T0N£S) 

(USABLE-SUCCESSORS-OF  (PR0JECT1  (-  II  1)))))) 

;  USABLE-SUCCESSORS-OF  « 

(LAMBDA  ( NOTE  1 ) 

(SET-OF  NOT £2  (TONES) 

(USA8LE- INTERVAL  (INTERVAL  NOTE  1  NOTE2 ) ) ) ) 

(STEP-ORDER  :  NIL) 

(STEP-TEST  : 

(LAMBDA  (II  N0TE3 ) 

(AMO  [MOT  (HIGHER  M0TE3  CLIMAX1)] 

[OR  [NOT  (=  CLIMAX  1  NOTE3 ) ] 

[NOT  (IN  CLIMAX  1  PRO JECT 1 ) ] ] ) ) ) 

(PATH-ORDER  :  NIL) 

(PATH-TEST  : 

(AND  [LAMBDA  (PROJECT1) 

(FORALL  INTERVAL!  ( INTERVALS-OF  PR0JECT1) 

( USA8LE - INTERVAL  INTERVAL1 ) ) ] 

[LAMBDA  ( PROJECT  1 ) 

(=<  (MELODIC-RANGE  PROJECT1)  (MAJOR  10))] 

[LAMBDA  ( PROJECT  1 ) 

(FORALL  XI  PROJECT  1 

(NOT  (HIGHER  XI  CLIMAX1)))-' 

[LAMBDA  ( PROJECT  1 ) 

(=<  (^OCCURRENCES  CLIMAX1  PR0JECT1)  1)])) 
(COMPLETION-TEST  : 

(LAMBDA  ( PROJECT  1 )  (IN  (LENGTH  PROJECT1)  ( LB  :  UB  8  15)))) 
( SOLUTION-TEST  : 

(LAMBDA  (PROJECT1) 

(AND  [IN  CL  I MAX  1  PROJECT1] 

[=<  (^OCCURRENCES  CLIMAX1  PR0JECT1)  1] 

[FORALL  XI  PROJECT  t  (NOT  (HIGHER  XI  CLIMAX1))] 
[FORALL  INfERVALi  ( IMTERVALS-OF  PROJECT1) 
(USABLE-INTERVAL  INTERVAL  1 ) ] 

[=<  (MELOOIC-RANGE  PROJECTl)  (MAJOR  10)])))) 

;  ASSUMING  (SELECT  CLIMAX1  (RANGE  (CLIMAX  PROJECT!))) 


The  search  thereby  specified  corresponds  to  the  refined  procedure  shown  in  Figure  3-3.  and  has 
the  following  features. 
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INITIAL 

PATH 

nil 


PRECOMPUTED  FUNCTION: 

usable  successor  tones 


INITIALIZED  VARIABLE: 

CLIMAX  1 


only  usable  intervals 
range  of  10th  or  less 
CLIMAX  1  unrepeated 
CLIMAX1  highest  note 


SOLUTION 


8  to  1 6  notes  long 
only  usable  intervals 
range  of  10th  or  less 
CL1MAX1  unrepeated 
CLIMAX1  highest  note 


CHOICE 

SET 


none  no  higher  than  CLIMAX1 


(function  of  path) 


don’t  repeat  CLIMAX1 


=  usable  successors  of  last  note  (any  tone  for  1st  note) 


Figure  3-8:  Refined  Search  for  Compose  Cantus 
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The  object  of  the  search  is  to  find  a  tone  sequence,  indexed  by  integer,  satisfying  the  solution-test 
and  completion-test. 

The  completion-test  specifies  that 

Cl.  The  cantus  be  from  S  to  16  notes  in  length. 

The  solution-test  specifics  that 

C2.  Every  interval  of  the  cantus  satisfy  the  usable-  interval  predicate. 

C3.  The  melodic  range  of  tire  cantus  not  exceed  a  major  tenth. 

C4.  The  preselected  climax  CLIMAX  l  occur  exactly  once  in  the  cantus. 

The  choice  set  at  each  point  in  the  search,  indexed  by  integer  variable  11,  consists  of  the 
USABLE-SUCCE5S0RS-0F  the  previous  note,  •-'xcept  that  the  initial  choice  set  includes  the  whole  set  of 
tones.  The  usable  successors  of  each  tone  can  be  precomputed. 

The  search  proceeds  by  choosing  a  path  from  the  active  path  list,  extending  it  by  one  element, 
testing  the  result  to  see  if  it's  a  solution,  and  deciding  whether  to  add  it  to  the  active  list.  The  first 
path  in  die  active  list  is  the  empty  sequence. 

The  step-test  is  used  to  test  possible  extensions,  so  that  sequences  containing  notes  higher  than 
CLIMAX1,  or  more  than  one  occurrence  of  CLIMAX1.  are  not  even  considered. 

The  path-test  is  used  to  test  generated  paths,  so  that  sequences  whose  melodic  range  exceeds  a 
major  tenth  arc  rejected. 

The  solution-test  is  used  to  test  possible  contuses:  sequences  not  containing  CLIMAX  l  are  rejected. 

The  search  terminates  successfully  when  it  finds  a  sequence  satisfying  both  the  solution-test  and 
die  completion-test.  By  the  construction  of  the  search,  any  such  sequence  will  satisfy  C1-C4. 


3.5.5.  Other  Possible  Refinements 

The  cantus  firmus  example  was  undertaken  to  test  the  generality  of  the  HSM  rules  used  in  the 
"avoid  taking  points"  example.  It  used  the  same  rules  for  initial  instantiation  of  die  HSM  schema, 
and  some  of  the  same  rules  for  refining  die  search.  It  is  instructive  to  look  at  the  other  HSM 
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refinement  rules  used  in  the  "avoid  taking  points"  example  and  consider  whether  they  too  could  have 
been  applied  to  the  canius  example.  Similarly,  one  may  ask  whether  the  rules  added  to  account  tor 
particular  refinements  could  be  used  to  make  other  refinements  as  well,  such  as  those  that  appear  in 
Meehan's  solution.  This  section  discusses  refinements  that  were  not  included  in  the  cantus  example 
but  could  have  been. 


3.5.5. 1  C  hanging  the  Initial-path 

* 

The  music  textbook  front  which  constraints  C1-C4  were  drawn  presents  several  other  constraints 
on  cantus  firmus.  One  of  these  is: 


"The  cantus  firmus  ...  must  begin  and  end  on  the  tonic.” 

* 


This  constraint  could  be  added  to  the  definition  of  LEGAL -CANTUS: 
( LAMSOA  (S) 

(AND  <previcjs  definition  of  L£GAL-CANTUS> 

[=  (FIRST  S)  (TONIC)] 

[=  (LAST  S)  (TONIC)])) 


The  constraint  could  be  moved  from  solution-test  to  step-test  by  RLT.H323  and  RULH327.  The 
first-notc-is-tonic  constrain*  could  then  be  compiled  out  of  the  search  by 

RULE332:  hi  tart  the  search  at  the  point  following  any  choices  determined  before  search  lime. 


This  would  change  the  initial  path  to  consist  of  the  tonic  note: 

(HSMl  WITH 

(STEP-TEST  :  4 

(LAMBDA  (II  NOTE  1) 

(AND  ...  [  =  >  [=  It  l]  [=  NOTE  1  (TONIC)]]  ...)))) 

-  [by  RULE332.  analysis]  - > 

(HSMl  <-  INITIAL-PATH  :  (LIST  N0TE2 ) ) 

(HSMl  <-  BINDINGS  :  ((TONIC))) 

( hSM  1  <-  VARIABLES  :  ( NOT E 2 )  )  * 


he  >ame  rule  was  used  in  the  "avoid  taking  points"  example  to  change  Lite  initial  path  to  the 
— * ;  •  cards  played  by  the  players  up  to  and  including  player  ME  (§3.4.2). 


f 
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3.5.S.2  Variabilizing  Cl 

Meehan's  program  simplified  constraint  Cl  on  the  length  of  the  cantus  by  asking  die  user  to 
specify  the  length  of  the  cantus  a  priori.  A  similar  effect  could  be  achieved  by  applying  a  rule  for 
preselecting  a  problem  feature  and  a  rule  for  constraining  choices: 

R  U  f  H256:  To  construct  an  object  s  so  as  to  satisfy  a  constraint  P(s,  J[ s)). 

Choose  a  value  c  forjfs). 

And  solve  the  two  subproblems  P(s,  c)  andjjs)  =  c. 

RULEI56:  To  achieve  P(...  c ...)  where  c  is  chosen  from  S, 
choose  c  from  {x  in  S  /  P(...  x  ...)}. 


These  rules  would  be  applied  to  the  cantus-length  constraint  in  the  solution-test: 

(IN  (LENGTH  PR0JECT1)  ( LB : U8  8  16)) 

-  [by  RULE256,  analysis]  - > 

(AND  [IN  LENGTH  1  (L8:UB  8  16)] 

[*  (LENGTH  PROJECT  1 )  LENGTH1 ] ) 

;  ASSUMING  (SELECT  LENGTH  1  (INTEGERS)) 

-  [by  choice  constraint,  analysis]  - > 

(HSM1  <-  COMPLETION-TEST  : 

(LAMBDA  ( PROJECT 1 ) 

(=  (LENGTH  PROJECT  1 )  LENGTH  1 ) ) ) 

;  ASSUMING  (SELECT  LENGTH1  ( LB ; UB  S  16)) 


This  refinement  specifies  that  lengthi  is  chosen  before  die  search.  The  choice  could  be  made 
randomly  or  by  asking  Lhe  user  for  a  number  between  8  and  16. 

3.5.S.3  Using  C'4  to  Order  the  Search 

The  cantus  example  does  not  include  step-order  or  padvorder  criteria  for  directing  the  search  as  in 
die  Hearts  example,  but  such  criteria  could  be  derived  using  the  same  rules: 

RULF335:  If  the  solution- test  includes  a  nwnotonicaHy  sufficient  constraint  P 
Then  add  P  to  the  path-order. 

RLL.F33S:  If  the  path-order  contains  a  constraint  P  on  paths  x{ ...  .r 
And  P(x j ...  XjJ  is  equivalent  to  QjXjJ, 

Then  add  0  to  the  step-order. 


These  rules  were  used  in  the  "avoid  taking  points"  example  to  re-order  the  search  so  as  to  consider 
card  sequences  with  points  first.  !n  die  cantus  example,  they  could  be  applied  to  a  clause  of  the 
unique-climax  constraint  C4  in  the  solution-test: 
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(IN  CLIMAX1  PROJECT  1 ) 


This  clause  would  be  moved  into  the  step-order  in  the  form 

( LAM8DA  (II  NOTE  1 ) 

(OR  [IN  CLIMAX1  PROJECT  1] 

[=  NOTE  1  CLIMAX!])) 


This  would  reorder  the  search  to  use  CLIMAX l  first  when  extending  a  note  sequence  in  which  it 
does  not  occur.  However,  this  would  produce  the  musically  undesirable  effect  of  always  selecting 
CLIMAXl  as  tiae  first  tone  of  the  cantus.  Actually,  this  effect  would  not  be  produced  by  a  faithful 
rendering  of  the  original  textbook  version  of  C4: 

"Kach  cantus  firmus  must  contain  a  climax  or  high  point.  This  tone  will  sene  as  the  goal  of  a 
motion  from  the  first  tone  of  the  cantus:  it  will  simultaneously  function  us  the  beginning  of  a 
second  melodic  cune  down  to  the  final  tone.  The  climax  tone  should  not  be  repeated.'' 

In  encoding  C4  1  omitted  die  italicized  sentence  because  it  wasn't  obvious  how  to  formalize  such 
vague  concepts  as  "the  goal  of  a  motion”  and  "melodic  curve”  without  reading  extra  meaning  into 
the  text  and  thereby  doing  a  lot  of  operationalization  myself.  Incorporating  additional  textbook 
constraints  in  the  definition  of  LEGAL-CANTUS  would  moderate  the  effect  of  using  C4  to  order  the 
search  and  prevent  the  unmusical  selection  of  CLIMAXl  as  the  first  note.  Hvcn  then,  using  C4  to  order 
the  search  might  be  counter-productive,  since  it  would  tend  to  include  CLIMAXl  as  early  as  possible 
in  the  cantus,  contrary  to  aesthetic  considerations.  This  refinement  is  heuristic  in  nature:  its  utility 
would  depend  strongly  on  the  other  constraints  in  the  search  criterion  and  on  the  other  refinements 
made.  Given  the  definition  used  in  the  example,  such  a  re-ordering  is  a  legitimate  refinement  since  it 
would  avoid  considering  complete  paths  in  which  CLIMAXl  did  not  occur. 


3.5.5.4  Converting  C3  to  a  Step-constraint 


One  could  use  C3  to  order  the  search  by  preferring  extensions  that  do  not  increase  the  melodic 

range.  This  preference  might  be  derived  mechanically  in  the  form  of  a  step-order  as  follows: 

( HSMl  WITH 

(PATH-TEST  : 

(LAMBDA  ( PROJECT  1 ) 

(AND  [  =  <  (MELODIC-RANGE  PROJECT  1 )  (MAJOR  10)]  ...)))) 

---  [by  RULE338a]  ---> 

(HSMl  <-  STEP-ORDER  : 

(LAMBOA  (II  NOTE I) 

(O  [=<  (MELODIC-RANGE  PR0JECT1)  (MAJOR  10)] 

[=<  (MELODIC-RANGE 

(APPEND  PROJECT  1  (LIST  NOTE  1 ) ) ) 

(MAJOR  10)]))) 


§.*.5.5.4.  Converting  C3  to  a  Step-constraint 


171 


---  [SUFFICE  by  RULE383]  ---> 

( LAMBDA  (II  NOTE  1 ) 

(=<  (MELODIC-RANGE  (APPEND  PROJECT1  (LIST  NOTE  1 ) ) ) 
(MELOOIC-RANGE  PROJECT  1 ) ) ) 

—  [by  analysis]  ---> 

(HSM1  <-  STEP-ORDER  : 

(LAMBOA  (II  NOTE1 ) 

(AND  [NOT  (LOWER  NOTE  1  (LOWEST  PROJECT1))] 

[NOT  (HIGHER  NOTE  1  (HIGHEST  PROJECT  1 ))])) ) 


This  refinement  could  be  accounted  for  by  a  rule  like 

RULE338a:  If  the  path- lest  contains  a  constraint  P  on  paths  xj ... 

And  the  inductive  condition  P(x. ...  —>  P(x; ...  x\J  reduces  to  Q(x,J, 

Then  add  Q  to  the  step-order. 

This  hypothetical  rule  strongly  resembles  a  rule  used  in  the  Hearts  example: 

RULH338:  If  the  path-order  contains  a  constraint  P  on  paths  x. ...  x 
And  P(x  ...  x,J  is  equivalent  to  Q(x,J, 

Then  add  Q  to  the  step-order. 

Ifie  effect  of  this  refinement  would  be  to  prefer  to  extend  a  sequence  without  extending  its 
melodic  range,  which  is  not  strictly  necessary  to  stay  within  the  bounds  specified  by  C3. 


The  exact  condition  for  C3,  formulated  as  a  step-tese  would  be 
(LAMBDA  (II  NOTE  1 ) 

(AND  [  =  <  (SIZE  (INTERVAL  (LOWEST  PR0JECT1)  NOTE  1 ) )  (MAJOR  10)] 
[«<  (SIZE  (INTERVAL  NOTEl  (HIGHEST  PROJECT  1 ) )  (MAJOR  10)]) 


The  effect  of  this  step-test  would  be  to  avoid  choosing  a  note  more  than  a  major  tenth  above  the 
lowest  note  so  far  or  more  than  a  major  tenth  below  the  highest  note  so  far.  Deriving  this  condition 
mechanically  appears  to  require  expanding  the  definition  of  MELODIC-RANGE  down  to  a  low  level  of 
detail,  or  else  using  a  fair  amount  of  specific  know  -edge  about  interval  arithmetic. 

3. 5. 5.5  Varialiili/ing  and  Precomputing  C3 

It  is  interesting  to  note  that  Meehan  simplified  constraint  C3  in  his  program  by  asking  the  user  to 
spcctfv  a  priori  die  lowest  and  highest  permissible  tones,  and  then  restricted  his  generator  to  the 
interval  spanned  by  them,  roo's  refinement  rules  are  nearly  adequate  to  derive  this  solution: 

(=<  (MELODIC-RANGE  PROJECT  1 )  (MAJOR  10)) 

-  [by  RULE256 1 ,  antisymmetry  of  =<]  - > 
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(AND  [=<  MELOO  IC -RANGE  1  (MAJOR  10)] 

[=<  (MELOOIC-RANGE  PROJECT1)  MELOO IC-RANGE  1  ] ) 
;  ASSUMING  (SELECT  MEL00IC-RANGE1  (INTEGERS)) 


This  transformation  uses  a  variant  of  the  rule  that  suggested  prc-seiecting  the  climax  tone: 

RULE256a:  To  construct  an  object  s  so  as  to  satisfy  a  constraint  P(s.j{s)), 

Choose  a  value  c  for  J( s). 

Ami  solve  the  two  problems  P(s.  c)  =>  P(s,  j( s))  andj(s)  =  c. 


The  idea  here  is  to  choose  MELOO  IC-RANGE 1  a  priori  and  then  use  it  to  limit  die  actual  range  of  the 
generated  camus.  This  goal  can  be  achieved  as  follows: 

(=<  (MELOOIC-RANGE  PROJECT1)  MEL0DIC-RANGE1 ) 

- [by  RULE124.  RULE27U]  ---> 

(=<  (SIZE  (INTERVAL  (LOWEST  PROJECT1)  (HIGHEST  PR0JECT1))) 

(SIZE  INTERVAL1 ) ) 

;  MELODIC -RANGE  1  <-  (SIZE  INTERVAL1 ) 

—  [by  analysis.  RULE271a]  — > 

( SU8SET  (INTERVAL  (LOWEST  PR0JECT1)  (HIGHEST  PR0JECT1)) 

(INTERVAL  LOWEST!  HIGHEST  1 ) ) 

;  INTERVAL1  <-  (INTERVAL  L0WEST1  HIGHEST  1 ) 

—  [by  analysis]  — > 

(AND  [NOT  (LOWER  (LOWEST  PROJECT1)  LOWEST1)] 

[NOT  (HIGHER  (HIGHEST  PROJECT!)  HIGHEST!)]) 


Here  RULE271a  can  be  paraphrased  as: 

Assume  an  unbound  variable  compared  to  an  expression  can  be  expressed  in  a  similar  form. 


This  idea  is  expressed  inure  precisely  (§5.4.2)  as 

RUL.F.271a:  (R  [f  Cj ...  ej  e)  ->  (R  [f  Cj  ...  cj  [f  Vj  ...  vn]),  assuming  e  =  (f  v;  ...  vj 


Thus  simplified,  C3  can  be  moved  from  the  solution-test  to  die  paui-test  by  RULE323.  dien  to  the 

step-test  by  RULE327  and  some  analysis  based  on  die  transitivity  of  LOWER  and  higher: 

( HSMl  <-  STEP-TEST  : 

(LAMBDA  til  NOTE  l ) 

(AND  [NOT  (LOWER  NOT  El  IOWESU)] 

[NOT  (HIGHER  NOK1  HIGHEST!)]))) 


C3  can  then  be  moved  from  the  step-test  into  the  c  loice-set  by  RLLF.384.  and  replaced  with  a 
prccomputablc  function  by  RUFF.386  (which  suggest  d  precomputing  USA3LE-SUCCESS0RS-0F): 


§3.5.5. 5.  Variabilizing  and  Precomputing  C3 
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(HSMl  <-  CHOICE-SETS  : 

(LAMBDA  (II) 

(TONES-BETWEEN  L0WEST1  HIGHEST  1) )) 


The  prccomputablc  function  synthesized  in  this  case  would  be 

TONES-BETWEEN  = 

(LAMBDA  ( NOTE  1  NOTE2) 

(SET-OF  N0TE3  (TONES) 

(AND  [NOT  (LOWER  N0TE3  NOTE  1 ) ] 

[NOT  (HIGHER  NOTE3  NOTE2 ) ] ) ) ) 


This  function  could  be  precomputed  and  stored  in  a  two-dimensional  table,  or  computed  quickly 
at  search  time  by  a  loop  of  the  form 

For  NOTE3  from  NOTE1  to  N0TE2 

Do  <try  using  N0TE3  to  extend  the  current  path> 


Meehan's  program  uses  this  kind  of  loop  to  generate  candidates  for  the  next  note.  Adding  rules  to 
FOO  on  using  iteration  to  generate  choice  sets  would  probably  involve  defining  an  explicit  iteration 
construct  and  representing  the  concept  of  successor  function. 


3.S.5.6  Satisfying  C4  without  Prcdeterming  the  Climax 

One  limitation  of  the  solution  in  the  cantus  example  (and  of  Meehan's  program)  is  the  requirement 
that  the  climax  tone  be  pre-selected.  The  mechanical  derivation  of  a  strategy  for  satisfying  C4 
without  choosing  the  climax  a  priori  is  demonstrated  in  DFRIV14  (§2.11).  DHRIV14  treats  C4  in 
terms  of  temporal  goals,  where  the  sole  action  consists  of  extending  the  cantus  by  another  note.  A 
general  rule  for  achieving  a  goal  over  time  is 

RU1.H258:  (achieve  P)  ->  (and  [  =  >  [not  P|  [cause  P]]  [  =  >  P  [not  (undo  P)|]) 

Achieve  a  goal  by  making  it  true  if  it  isn't,  and  not  undoing  it  if  il  is. 


Translating  dais  goal-oriented  rule  into  die  HSM  paradigm  yields  a  refinement  rule: 

Rl'I.F258a:  (HSM  with  (solution-test :  (lambda  (s)  (and  ...  [P  s) ...)))) 

->  (HSM  with  (step-order :  (lambda  (i  e)  (and  Qc  Rc)))) 

where  Qc  is  the  result  of  simplify  mg  (  =  >  [P  sj  fP  (append  s  (list  c))j) 
and  Rc  is  die  result  of  simplifying  (  =  >  [not  (P  s)[  [1*  (append  s  ( list  el'll) 

solution- test  contains  a  constraint  P  on  a  path  x  t ...  x ^ 
ftnd  P(xf ...  xk  j)  =>  P(x [ ...  x.)  reduces  to  Q(x.J 
And  ~P(x, ...  ,<k  /)  ->  P(x[ ...  xf  reduces  to  RfxJ. 

Then  pul  Q  and  R  into  the  step-order. 
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This  rule  is  not  as  logically  rigorous  as  the  rules  about  montonically  necessary  and  sufficient 
conditions;  it  assumes  that  extensions  of  a  path  satisfying  some  constraint  tend  to  satisfy  it  also.  This 
assumption  of  "inertia"  or  "monotonicity'’  has  obvious  counter-examples.  For  instance,  if  you  want 
to  give  a  dinner  party  next  week  and  need  to  defrost  your  roast  first,  taking  it  out  of  the  freezer  today 
is  unlikely  to  help  you  achieve  your  goal  of  having  a  good  party.  Or  if  you  want  to  leave  on  a  bicycle 
trip  tomorrow,  you  will  need  to  unlock  your  bicycle  and  move  it  in  front  of  your  house,  but  it  may 
not  stay  there  overnight  if  you  do  it  now.  Thus  the  monotonicity  assumption  can  fail  in  domains 
where  there  are  other  agents,  e.g..  bacteria  and  bicycle  thieves. 

Even  if  die  constraint  in  question  continues  to  hold  when  the  path  is  extended,  a  refinement  may 
be  bad  because  it  interferes  with  other  constraints.  As  mentioned  earlier,  re-ordering  the  search  to 
use  the  climax  tone  as  early  as  possible  violates  aesthetic  criteria  on  the  melodic  contour  of  the  cantus. 
Similarly,  playing  the  Queen  of  Spades  at  the  first  opportunity  when  try  ing  to  shoot  die  moon  in 
Hearts  violates  die  goal  of  concealing  one’s  intentions  from  opponents,  even  though  die  subgoal  of 
taking  die  Queen  will  remain  fulfilled. 

3.S.5.7  Depth-first  versus  lircadth-first  Search 

A  depth-first  search  order  could  be  achieved  by  changing  the  initial  path-order  to 
(lambda  (S)  (LONG  S)).  Here  the  fuzzy  predicate  LONG  returns  a  value  proportional  to  the  length 
of  die  path.  This  assumes  diat  die  mechanism  that  evaluates  operational  expressions  at  runtime  can 
handle  fuzzy  logic.  For  example,  fuzzy  truth  values  could  be  represented  as  real  numbers  between  0 
and  1.  and  combined  arithmetically  to  compute  boolean  combinations.  A  disjunction  of  fuzzy  truth 
values  might  be  evaluated  by  taking  their  maximum.  Other  boolean  operators  might  correspond  to 
minimum,  complement,  sum,  product,  average,  etc. 

Best  first  behavior  might  be  achieved  by  combining  die  predicate  LONG  with  domain-specific 
criteria  based  on  mononionically  sufficient  conditions  derived  from  the  solution-test  in  the  manner 
illustrated  in  the  examples.  This  would  focus  die  search  on  well-developed  partial  paths  satisfying 
several  constraints. 

Conversely.  IvwiJthfrst  search  could  be  implemented  giving  equal  priority  to  all  branches  of  die 
search  tree.  This  could  be  achieved  by  incorporating  in  die  path-ordu-  the  fuzzy  predicate 
(lambda  (S)  (SHORT  S > ) .  This  option  appears  inappropriate  for  either  die  Hearts  or  die  music 
example.  Breadth-first  behavior  decreases  the  risk  of  squandering  limited  resources  in  exploring  the 
extensions  of  a  poor  choice  made  early  in  die  choice  sequence,  at  the  eost  of  slowing  down  progress 
toward  a  solution  by  cautiously  examining  inferior  alternatives  along  the  way. 


§3.5.5.7.  Depth-first  versus  Breadth-first  Search 
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An  interesting  direction  for  future  research  is  to  characterize  the  situations  in  which  each  of  these 
alternatives  is  most  effective.  For  example,  breadth-first  search  may  be  appropriate  when  solutions 
are  sparsely  distributed  in  the  search  space  and  there  are  no  good  heuristics  for  evaluating  the  relative 
promise  of  a  given  path,  Le..  predicting  whether  it  can  be  extended  into  a  solution. 


3.6.  Evaluation  of  the  Experiment 

Attacking  a  problem  in  a  second  task  domain  provided  a  way  to  test  the  generality  of  tOO's 
knowledge  about  operationalizing  advice  in  terms  of  HSM,  and  the  ov  erall  viability  of  the  approach. 
The  generality  issue  divides  into  three  parts  corresponding  to  different  pans  of  this  knowledge: 

1.  The  HSM  schema  itself. 

2.  The  rules  for  instantiating  the  HSM  schema  initially. 

3.  The  rules  for  refining  the  search. 

3.6.1.  Generality  of  the  HSM  Schema 

The  same  schema  was  used  for  both  the  Hearts  and  the  music  examples.  Some  components  were 
added  in  the  course  of  developing  the  first  example,  like  the  initial-path  and  variables,  but  they 
proved  useful  in  the  second  problem  as  well.  It  would  be  necessary  to  add  or  generalize  components 
to  handle  certain  other  problems  --  for  instance  problems  in  which  die  initial  state  is  a  set  of  padis 
rather  than  a  single  path.  For  some  problems  it  would  be  useful  to  have  a  test  applied  only  to  the 
initial-path,  or  to  specialize  the  step-constraints  into  different  predicates  based  on  the  arguments  they 
require.  For  instance,  some  of  die  tests  depend  on  the  path  variable,  and  some  only  on  the  element 
to  be  used  for  extending  die  padi.  hcsuniablv  die  latter  arc  cheaper  to  evaluate  than  the  former. 

Endless  variations  on  the  generic  search  procedure  arc  possible,  and  each  one  has  cases  where  it 
would  be  useful.  It  would  be  interesting  (and  no  doubt  quite  challenging!)  to  mechanize  die  analytic 
process  involved  in  inventing  such  modifications.  A  prerequisite  of  such  an  effort  is  a  way  to 
represent  modifications  to  HSM.  MF.RI.1N  was  able  to  represent  some  of  these  as  "further 
specifications'-  of  an  abstract  description  [Moore  “4j.  loo's  schema  has  the  advantage  of  offering  a 
fixed  target  for  a  set  of  instantiation  and  refinement  rules,  and  appears  quite  adequate  to  handle  both 
the  examples  presented  in  this  chapter.  Hovvevcr.  using  a  fixed  collection  of  control  components 
precludes  the  use  of  graph  transformations.  >ueh  as  splitting  die  search  procedure  into  several  copies 
and  specializing  each  one  to  handle  a  separate  case.  A  more  powerful  approach  would  represent 
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refinements  as  transformations  on  flow  graphs.  This  approach  has  been  used  to  design  efficient 
algorithms  for  generating  prime  numbers  and  finding  shortest  paths  through  a  graph  [Tappc!  80],  and 
appears  to  be  a  promising  avenue  for  future  research. 

3.6.2.  Generality  of  the  Schema  Instantiation  Process 

The  process  of  initially  instantiating  the  1ISM  schema  is  almost  the  same  in  the  two  examples,  step 
for  step;  the  same  HSM  rules  are  applied  in  the  same  order,  although  tire  analysis  required  in 
between  often  differs  substantially.  The  only  deviation  from  the  common  path  occurs  in  the  process 
of  fixing  up  the  initial  instantiation  to  make  it  executable.  In  the  Hearts  example,  tills  consists  of 
broadening  the  choice  set  to  make  it  evaluable,  and  then  finding  evaluable  predicates  with  which  to  ,, 

filter  it  back  down  (§3.3.4).  The  rules  used  to  fix  up  the  Hearts  example  do  not  apply  in  an  obvious 
way  to  the  music  example,  but  appear  related  more  to  tine  problem  of  reformulation-for-evaluability 
than  to  HSM  perse.  In  the  music  example,  die  only  fix  is  to  replace  an  undefined  completion-test 
with  a  problem  constraint  (§3.5.1)  in  order  to  compensate  for  a  limitation  of  l  OO's  representation  2 

scheme. 

The  striking  parallelism  bctw-ccn  the  instantiation  process  in  the  two  examples  provides  supporting 
evidence  for  the  generality  of  that  process.  , 

3.6.3.  Generality  of  the  Refinement  Process 

The  generality  of  the  refinement  rules  developed  for  the  Hearts  example  was  tested  by  checking  to  t 

see  which  of  them  could  be  applied  to  the  music  example.  Some  of  them,  like  RUI  H323  and 
RUI.H327,  were  directly  and  repeatedly  applied  in  the  music  example.  Others  are  very  similar  to 
rules  used  in  die  music  example:  RUI.E389  resembles  RUL  K338  in  form,  and  RULH333  resembles 
RULE256  in  spirit.  Finally.  •  ime  Riles,  like  RUL.E332  and  RULE335,  were  not  actually  used  in  the  t 

new  example  but  could  have  been.  By  these  criteria,  every  refinement  rule  used  in  the  Hearts  example 
was  (or  resembled  a  rule )  applicable  to  the  music  example.  The  eases  of  close  resemblance  between 
rules  suggest  dial  it  may  be  worthwhile  to  look  either  For  common  generalizations  or  for  a  more 
fundamental  rule-generating  process.  • 

Conversely,  one  can  ask  how  many  refinement  Riles  were  added  to  cover  the  music  example,  not 
counting  Riles  that  were  almost  die  same  as  old  ones.  The  new  Riles  were; 

RUI  .F256  for  splitting  a  constraint  into  choose  now  --<olvc  later  form,  which  resembles  in  spirit  * 

RL1.1333  for  variabili/ation; 


§3.6.3.  Generality  of  the  Refinement  Process 
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RULE384  for  moving  a  step-test  into  a  generator; 

RULE3S6  for  recognizing  precomputablc  functions,  an  idea  not  specific  to  refining  HSM; 

RULE389  for  moving  a  path-test  to  a  step-test,  which  resembles  in  form  the  old  RULE338  for 
moving  a  path-order  to  a  stop-order;  and 

RULE390,  which  uses  an  inductive  property  of  the  search  to  simplify  step-constraints,  and  is 
really  an  analysis  rule  that  expresses  a  fact  about  HSM. 

However,  none  of  these  rules  appears  specific  to  music.  1  did  not  explore  the  possibility  of 
applying  them  to  the  Hearts  example. 

According  to  the  criteria  above  -  applicability  or  similarity  --  all  the  refinement  rules  used  in  the 
Hearts  example  were  general  within  the  scope  of  the  two  examples,  and  tine  ones  added  to  handle  the 
music  example  were  similar  to  old  rules  or  of  general  interest  in  their  own  right.  In  contrast,  many 
additional  analysis  rules  were  added  for  the  music  example  to  solve  the  subproblems  generated  by 
the  HSM  rules. 

3.6.4.  Conclusions  on  Generality 

The  experiment  provides  about  as  much  evidence  as  one  could  hope  to  get  from  just  two  examples 
for  the  generality  of  t'OO's  knowledge  about  HSM  and  the  process  of  applying  it  to  problems  in  a 
given  task  domain.  The  rules  that  applied  to  one  example  but  not  the  other  appear  to  fall  in  three 
categories: 

1.  Rules  that  deal  with  problem-specific  artifacts  unrelated  to  HSM  per  se.  such  as  changing  the 
choice  set  to  make  it  evaluable. 

2.  Rules  whose  purpose  is  not  specifically  ''operationalization  in  terms  of  HSM,”  e.g.,  rules  to 
perform  analysis  or  identify  precomputablc  functions. 

3.  Rules  similar  in  form  or  purpose  to  rules  used  in  the  other  example,  but  syntactically  or 
functionally  not  general  enough  to  be  used  directly  in  die  other  example,  e.g..  a  rule  that  moves 
constraints  from  padi-test  to  step-test  but  not  from  padi-ordcr  to  step-order. 

The  fact  that  the  HSM  rules  used  in  die  two  examples  overlapped  to  such  a  great  extent  and  were 
used  more  than  once  within  the  same  example,  while  the  analysis  problems  they  generated  required 
dissimilar  rales,  suggests  that  TOO  docs  indeed  have  some  general  knowledge  about  the  instantiation 
and  refinement  processes  involved  in  operationalizing  a  problem  in  terms  of  HSM. 
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Chapter  4 
Reformulation 

The  most  common  activ  ity  exhibited  in  the  example  derivations  is  the  reformulation  of  expressions 
to  fit  the  run-time  capabilities  of  the  task  agent,  or  the  requirements  of  a  particular  method.  Often 
this  is  only  implicit  in  the  directionality  of  the  derivation:  a  sequence  of  reformulation  steps  precedes 
the  application  of  a  significant  operationalization  or  problem  reduction  method,  but  the  goal 
"reformulate  the  expression  so  this  method  can  be  applied”  is  not  explicitly  represented  in  the 
derivation. 

The  rest  of  this  chapter  is  organized  according  to  different  kinds  of  reformulation  problems ,  rather 
than  the  methods  used  to  solve  them.  (§4.1)  explains  the  difficulty  of  representing  such  problems 
explicitly.  (§4.2)  describes  two  important  classes  of  explicit  reformulation  problems.  (§4.3)  discusses 
several  kinds  of  reformulation  problems  implicit  in  the  derivations.  Finally,  (§4.4)  re-examines  the 
explicit/implicit  distinction  and  presents  a  taxonomy  of  reformulation  problems. 


4.1.  Representation  of  Literal  Expressions 

Consider  the  problem  of  explicitly  representing  a  reformulation  goal  lik„ 

“Transform  (GET-LEAD  me)  into  an  equality.” 

This  goal  refers  to  the  literal  expression  (GET- LEAD  ME)  as  opposed  to  the  action  it  denotes. 
However,  the  knowledge  representation  used  in  FOO  provides  no  way  to  refer  to  the  form  of  literal 
expressions:  expressions  are  considered  semantically  equivalent  if  they  denote  the  same  entity.  This 
limitation  applies  only  to  the  expression  language,  not  to  die  rules.  A  rule  condition  can  test  whether 
an  expression  has  a  particular  form,  either  by  matching  it  against  a  variabilized  pattern  or  by  using  a 
procedure  to  examine  its  internal  representation.  However,  a  predicate  on  the  form  of  an  expression 
would  require  as  its  argument  some  representation  of  die  literal  expression.  In  I. ISP,  the  literal 
object  e  is  denoted  e.  This  construct  might  be  used  to  represent  the  goal  of  transforming 
(GET -LEAD  ME)  into  an  equality: 


hxECKDlNG  1*0*  BUNK -NOT  HUB 
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"Find  /’s.t.  (Interpretation  P)  =  (Interpretation  '  (GET-LEAD  ME))and(Car  P)  =  “  = 

Here  the  variable  P  takes  as  its  value  a  literal  expression,  whose  meaning,  denoted  by 
(Interpretation  P).  is  required  to  be  semantically  equivalent  to  (GET-LEAD  ME).  Representing  a 
constraint  on  the  form  of  an  expression  may  require  knowledge  about  how  expressions  arc  encoded  in 
the  machine.  Thus  the  requirement  that  P  be  an  equality  is  expressed  as  (Car  P)  =  '  =  ,  where  ’  = 
denotes  die  literal  symbol  tor  equality.  This  assumes  drat  expressions  are  encoded  in  I  .ISP  prefix 
notation.  However,  representing  literal  expressions  has  the  disadvantage  of  violating  the  referential 
transparency  of  the  representation.  Moreover,  the  'e  construct  does  not  handle  the  case  where  e  has 
variables,  c.g..  (GET-LEAD  Pi ).  Similar  difficulties  arise  when  one  tries  to  represent  such  notions  as 
“knowing  that  X  is  taie"  or  "knowing  the  value  of  X.”  Modal  logic  has  been  used  to  represent  the 
"knowing”  relation  [McCarthy  71). 


4.2.  Explicit  Reformulation  Problems 

It  is  possible  to  represent  explicitly  certain  important  classes  of  reformulation  problems  without 
having  to  represent  literal  expressions  and  operations  on  their  structure.  One  such  class  contains 
problems  of  the  form 

Reformulate  expression  e  in  terms  of  concept  f. 

These  problems  can  be  represented  as  equations  of  the  form 
e  =  h(^xt . xk)) 

In  these  equations,  the  function  h  and  arguments  x t .  xk  arc  die  unknowns.  Another  class 

contains  problems  of  die  form 

Reformulate  expression  e  as  a  function  of  quantity  e\ 

These  can  be  represented  as  equations  of  die  form 
e  =  /,-(e') 

Here  die  function  h  is  the  unknown.  For  both  classes  of  reformulation  problems,  die  equation  is 
solved  and  the  unknowns  are  replaced  by  their  values  to  yield  an  expression  of  die  desired  form. 
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4.2.1.  Reformulating  an  Expression  in  terms  of  a  Given  Concept 

The  first  kind  of  reformulation  problem  has  the  form 
Reformulate  expression  e  in  lenns  of  concept  f. 


Such  a  problem  is  illustrated  in  DER1V9.  Here,  fis  the  predicate  DISJOINT  ande  is 
(EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO)) 


Since  this  expression  is  a  predicate  on  the  unknown  set  (CARDS-IN-HAND  PO),  it  makes  sense  to 
reformulate  it  in  terms  of  the  predicate  DISJOINT  to  match  the  problem  statement  for  the  disjoint 
subsets  method  (§2.3).  The  reformulation  problem  is  set  up  as  an  explicit  equation: 

9:2  ---  [by  RULE189]  ---> 

(=  (EXISTS  Cl  (CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO)) 

(HI  (DISJOINT  (CARDS-IN-HAND  PO)  SI))) 


The  first  step  toward  solving  for  Hi  is  to  plug  in  the  definition  of  DISJOINT: 

9:3-4  ---  [ELABORATE  by  RULE  124]  ---> 

(=  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO)) 

(HI  (NOT  (EXISTS  XI  (CARDS-IN-HAND  PO)  (IN  XI  SI))))) 


If  tile  two  terms  of  the  form  (EXISTS  .  .  . )  can  be  proved  equal.  Hi  can  be  solved  for  by 
RULE212:  ( =  c  (h  (...  e’ ...)))  ->  (  =  h  (inverse  (lambda  (x)  (...  x  ...))))  if  e  =  e’ 


A  value  of  SI  is  found  that  makes  the  two  terms  equal: 

(«  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO)) 
(EXISTS  XI  (CARDS-IN-HAND  PO)  (IN  XI  SI))) 

9:6-13  -  [by  analysis]  - > 

T 

(SI  <-  BINDING  :  (CARDS- IN-SUIT  SO)) 


The  recurrence  rule  RULK212  (§5.3.5)  gives  a  solution  (there  may  be  others)  for  the  function  Hi: 

(=  HI  (INVERSE  (L4MB0A  v EX ISTS 1 )  (NOT  EXISTS1)))) 

9:15 - [simplify] - > 

(=  HI  (INVERSE  NOT)) 


This  yields  the  function  NOT  (which  happens  to  be  its  own  inverse)  as  die  value  of  Hi. 
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|  4.2.2.  Reformulating  an  Expression  as  a  Function  of  a  Given  Quantity 

I 

1  A  second  class  of  reformulation  problems  have  the  form 

Reformulate  expression  easa  function  of  quantity  e’. 

Such  problems  are  illustrated  in  DF.RIV2  and  DERIV'D  (§3).  Once  the  CHOICES  slot  of  the 
instantiated  HSM  has  been  filled  in  with  the  sequence  of  objects  to  be  chosen,  RULF.314  proposes  to 
reformulate  the  initial  problem  as  a  function  of  this  sequence.  In  DERIV2.  this  is  the  sequence 
(CAROS- played)  of  cards  played  in  the  trick;  in  DERIV'D,  the  sequence  consists  of  die  notes  in  the 
cantus.  For  convenience,  the  derivations  use  the  notation  (reformulate  e  e-)  rather  than  the  equation 
e  =  Me’).  Once  the  problem  is  massaged  into  the  form  (reformulate  (f ...  e‘  ...)  o'),  RUI.F315  notices 
the  recurrence  on  c’  and  reformulates  e  as  ([lambda  (x)  (f ...  x  ...)]  e‘). 

Problems  of  the  form  "reformulate  P  as  a  predicate  Q  universally  quantified  over  the  set  of  path 
indices"  are  generated  by  RULE327  at  steps  2:74.  13:28.  and  13:72  in  the  course  of  moving 
constraints  from  the  path-test  to  the  step-test  (§3.4.1).  Each  such  problem  is  represented  as  an 
equation  of  the  form  P  =  (forall  i  (indiccs-of  path)  Q). 

A  somewhat  similar  problem  is  generated  in  DF.R1Y9  by  the  decision  to  approximate  die 
probability  that  player  PO  is  void  in  suit  SO  as  a  function  of  SO  (§2.8).  This  problem  has  the  form 

Reformulate  expression  e  as  a  Oih- order  approximate  function  of  e' 

[  he  problem  (generated  by  RUFE202  at  step  9:44)  is  not  represented  as  an  equation  of  die  form 
e  ~  hie').  Instead.  RUi.F203-2')8  arc  used  to  compute  (dependence  e  e')  --  essentially  the  sign  J  of 
the  partial  derivative  of  e  with  respect  to  c'  in  the  4-elcment  algebra  {f,  i.  0,  ?}  -  and  e  is  rewritten  as 
( FUNCT lON-QF  o'  J).  A  slight  complication  arises  because  it  is  impossible  to  partial-differentiate 
with  respect  to  a  non-continuous  variable,  in  this  case  the  suit  SO.  Phis  is  fixed  up  by  RL1.F210. 
which  finds  a  continuous  function  e"  of  e\  and  changes  the  problem  to  computing  J'  = 
(DEPENDENCE  c  e”)  and  approximating  e  as  (FUNCTION-OF  e"  J').  The  final  expression  is 
( FUNCT ION -OF  ( BOARDS -OUT- IN -SUIT  Su)  DECREASING) 

It  can  be  interpreted  as  “a  decreasing  function  of  die  number  of  cards  out  in  suit  SO."  This  giv  cs 
enough  information  to  order  the  suits  according  to  the  relative  probabilities  of  a  void  in  each  one. 
The  ordering  could  be  computed  by  the  task  agent's  win-time  evaluation  mechanism  (given  a  way  of 
computing  ( #C  ARDS  -  OUT  -  IN-SUIT  SO)  as  derived  in  DERIVE)  (§2.4.3))  and  used  in  applying 
advice  like  "Avoid  loading  a  high  card  in  a  suit  where  an  opponent  is  void." 


§4.2.2.  Reformulating  an  Expression  as  a  Function  of  a  Given  Quantity 
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4.2.2. 1  Identifying  Potentially  Applicable  Methods 

A  problem-solver  in  the  operationalization  problem  space  would  need  to  know  when 
reformulation  was  appropriate.  In  some  cases,  reformulation  is  explicitly  called  for  by  a  specific 
strategy  based  on  a  clue  in  the  problem,  e.g.,  “use  the  disjoint  subsets  method  to  estimate  a  predicate 
on  an  unknow  n  set"  In  other  cases,  reformulating  a  problem  makes  it  possible  to  apply  some  method 
to  it.  It  would  be  desirable  to  have  an  efficient  way  to  identify  problems  potentially  amenable  to  a 
known  useful  method.  One  approach  would  partial-match  an  expression  (f ...)  against  the  left-hand 
side  of  a  method,  and  use  a  near-match  as  a  clue  to  the  potential  applicability  of  the  method. 
Residual  mismatches  would  then  be  resolved  by  reformulating  (f...)  to  fit  the  method.  This  approach 
could  be  expected  to  fail  for  top-level  mismatches,  e.g.,  where  matching  the  method  requires 
elaborating  f.  Intersection  search  through  the  knowledge  base  might  help  identify  cases  in  which 
such  top-level  reformulation  enables  application  of  a  method.  A  similar  approach  is  described  in 
(§7):  the  general  issue  of  problem-solving  in  operationalization  is  discussed  in  (§8.1.1). 


4.3.  Implicit  Reformulation  Problems 

Implicit  reformulation  problems  occur  throughout  the  derivations,  but  seem  to  fall  into  a  small 
number  of  categories.  One  type  of  problem  involves  reformulating  an  expression  to  fit  the  task 
agent’s  run-time  capabilities  for  making  observations,  performing  actions,  and  making  choices. 
Another  involves  mapping  an  expression  into  the  form  required  by  a  method. 

4.3.1.  Reformulating  an  Expression  to  Fit  the  Run-time  Capabilities  of  the  Task 
Agent 

The  task  agent  is  assumed  to  have  run-time  capabilities  for  observing  certain  quantities  in  the  task 
environment,  computing  certain  functions,  and  executing  certain  actions  in  the  environment  (§1.1. 1)3 
Accordingly,  operationalizing  an  expression  may  involve  reformulating  it  as  an  observable  quantity,  a 
computable  function,  or  an  executable  action. 


0 

The  interactive  mode  of  operation  made  it  unnecessary  to  give  too  an  explicit  enumeration  of  run-time  capabilities;  the 
derivations  implicitly  reflect  die  knowledge  of  these  capabilities  that  1  jsed  :n  choosing  which  rules  :o  apply  This  is  only  one 
example  of  the  savings  in  work  afforded  by  factoring  probicm-soiving  issues  out  of  the  investigation. 
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4.3.1. 1  Reformulating  an  Expression  in  terms  of  Observables 


In  DIZR1V4,  the  pigeon-hole  principle  is  used  to  reformulate  (QS-OUT)  in  terms  of  evaluable 
quantities.  Part  of  the  derivation  consists  of  mapping  the  result  the  method  to  the  observable 
predicates  IN-POT  and  HAS-ME: 

(=  (LOC  QS)  POT) 

4:35  ---  [RECOGNIZE  by  RULE  123]  ---> 

(AT  QS  POT) 

4:40  ---  [RECOGNIZE  by  RULE123]  ---> 

(IN-POT  QS) 

(=  (LOC  QS)  (HAND  ME)) 

4:37  ---  [RECOGNIZE  by  RULE  123]  ---> 

(AT  QS  (HAND  ME)) 

4:41  ---  [RECOGNIZE  by  RULE  1 23 ^  ---> 

(HAS  ME  QS) 

4:42  ---  [RECOGNIZE  by  RULE  123]  ---> 

(HAS-ME  QS) 


I.ater,  the  abstract  action  "cause  to  be  at"  is  reformulated  as  the  observable  action  TAKE: 

(CAUSE  (AT  QS  (PILE  P3))) 

4:51  ---  [RECOGNIZE  by  RULE358]  ---> 

(MOVE  QS  LOCI  (PILE  P3)) 

4:52  ---  [RECOGNIZE  by  RULE  123]  ---> 

(TAKE  P3  QS) 


Reformulation  in  terms  of  observable  events  is  described  in  (§2.4).  This  kind  of  transformation  is 
also  used  in  DER1V10  to  reformulate  "undo  out"  as  the  observable  action  PLAY: 


(UNDO  (OUT  XI)) 

4:26 

(OUT  XI) 

---  [ELABORATE  by  RULE  124]  ---> 

(EXISTS  P3  (OPPONENTS  ME)  (HAS  P3  XI)) 

4:27 

(UNDO  (EXISTS  P3  (OPPONENTS  ME)  (HAS  P3  XI))) 

-  [UNCERTAIN  by  RULE329]  ---> 

(EXISTS  P3  (OPPONENTS  ME)  (UNDO  (HAS  P3  XI))) 

a :  28 

(HAS  P3  XI) 

---  [ELABORATE  by  RULE124]  ---> 
(AT  XI  (HAND  P3 ) ) 

4:29 

(UNDO  (AT  XI  (HAND  P3))) 

---  [RECOGNIZE  by  RULE368]  ---> 

(MOVE  XI  (HAND  P3)  LOC2) 

4:30 

---  [RECOGNIZE  by  RULE123]  ---> 

(PLAY  P3  XI) 

(EXISTS  P3  (OPPONENTS  ME)  (PLAY  P3  XI))) 

§4.3. 1.1.  Reformulating  an  Expression  in  terms  of  Observables 
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In  the  examples  above,  expressions  were  reformulated  in  terms  of  observable  conditions  and 
actions.  An  expression  might  also  be  reformulated  in  terms  of  an  observable  suite  function  other 
than  a  boolean  condition,  for  example,  (CARDS  -  IN-HAND  ME),  whose  value  is  a  set  of  cards. 


4.3.1.2  Reformulating  a  Goal  as  a  Function  of  a  Choice  Variable 


One  way  to  operationalize  a  goal  is  to  reformulate  it  as  a  computable  predicate  on  a  choice 
variable.  This  predicate  can  then  be  incorporated  in  an  evaluation  function  used  for  choosing  an 
optimal  value  for  the  variable. 


For  instance,  most  of  the  work  in  DF.RIV6  consists  of  reformulating  “avoid  taking  points"  as  a 

constraint  on  the  card  player  ME  chooses  to  play: 

(AVOID- TAKING- POINTS  (TRICK)) 

6:1  ---  [ELABORATE  by  RULE  124]  ---> 

(AVOID  (TAKE-POINTS  ME)  f TRICK) ) 

6:2  ---  [ELABORATE  by  RULE  124]  ---> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 

(TRICK) 

6:3  ---  [ELABORATE  by  RULE  124]  ---> 

(SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 
(TAKE-TRICK  (TRICK-WINNER))) 

(DURING  (SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 
(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME)) 

6:4-6  -  [by  case  analysis]  - > 

(OURING  (TAKE-TRICK  (TRICK-WINNER)) 

(TAKE-POINTS  ME)) 

(TAKE-POINTS  ME) 

6:7  ---  [ELABORATE  by  RULE124]  ---> 

(FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl)) 

(TAKE-TRICK  { TR ICK-WI NNER ) ) 

6:8  ---  [ELABORATE  by  RULE124]  ---> 

(EACH  C3  (CARDS-PLAYED) 

(TAKE  (TRICK-WINNER)  C3) ) 

(DURING  (EACH  C3  (CARDS-PLAYED) 

(TAKE  (TRICK-WINNER)  C3 ) ) 

(FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl))) 

6:9  ---  [COLLECT  by  RULE58]  — -> 

(EXISTS  C3  (CARDS-PLAYED) 

(OURING  (TAKE  (TRICK-WINNER)  C3) 

(FOR-SOME  Cl  (POINT-CARDS) 

(TAKE  ME  Cl)))) 
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(DURING  (TAKE  (TRICK-WINNER)  C3) 

(FOR-SOME  Cl  (POINT-CAROS) 

(TAKE  ME  Cl))) 

6:10  ---  [COLLECT  by  RULE100]  ---> 

(EXISTS  Cl  (POINT-CARDS) 

(DURING  (TAKE  ( TR ICK-WI NNE R )  C3) 
(TAKE  ME  Cl))) 


6:11-22 


6:24 


(DURING  (TAKE  (TRICK-WINNER)  C3) 
(TAKE  ME  Cl)) 

—  [by  RULE43,  simplification]  — > 
(AND  [*  (TRICK-WINNER)  ME] 

[TRICK-HAS-POINTS]) 

( TRICK-WINNER) 

-  [ELABORATE  by  RULE124]  ---> 

(PLAYER-OF  (WINNING-CARD)) 


6:25  ---  [ELABORATE  by  RULE  124 ]  ---> 

(THE  P2  (PLAYERS) 

(=  (CARD-OF  P 2)  (WINNING-CARD))) 


(=  (THE  P2  (PLAYERS) 

(=  (CARD-OF  P2)  (WINNING-CARD))) 

ME) 

6:26-28  ---  [REMOVE -QUANT  by  RULE  13 1 .  analysis]  ---> 

(ACHIEVE  (NOT  (AND  [»  (CARD-OF  ME)  (WINNING-CARD)] 
[TRICK-HAS-POINTS]))) 


This  expression  is  a  predicate  on  the  choice  variable  (CARD-OF  ME),  but  is  non-opcrational  since  it 
depends  on  die  unpredictable  (winninG-CARD).  The  rest  of  tiro  derivation  consists  of  reformulating 
the  expression  to  make  it  computable. 


A  similar  reformulation  occupies  most  of  DERIY7,  where  “get  the  lead"  is  reformulated  as  “win 
the  trick"  and  eventually  as  "play  a  high  card”. 

4.3. 1.3  Reformulating  a  Goal  as  an  Executable  Action 

Another  important  problem  that  arises  in  forming  a  plan  is  reformulating  an  abstract  event 
description  as  an  executable  action  (§2.4).  For  instance,  in  DF.RIY8.  much  of  the  process  of  deriving 
a  plan  to  flush  the  Queen  consists  of  finding  an  action  drat  will  get  rid  of  one  of  the  spades  held  by 
whoever  has  the  Queen: 

( REMOVE- 1 -FROM 

(SET-OF  C3  (DIFF  (CARDS)  (SET  QS))  (LEGAL  (QSO)  C3 ) ) ) 
3:41-51  —  [by  analysis]  — > 

(PLAY  (QSO)  C3 ) 


I'he  action  found  is  for  the  player  with  the  Queen  to  play  some  spade  C3.  The  rest  of  the 
derivation,  discussed  elsewhere  in  more  detail  (§2.5.2).  consists  of  figuring  out  how  to  force  player 
(QSO)  to  play  a  spade. 


§4.3. 1.3.  Reformulating  a  Goal  as  an  Executable  Action 
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A  similar  reformulation  problem  (§2.5.1)  occurs  in  DERIV’8  in  the  course  of  constructing  a  plan  to 
get  void  in  suit  SO: 

( REMOVE  - 1-FROM 

(SET-OF  Cl  (CAROS- IN-HAND  ME)  ( IN-SUIT  Cl  SO))) 

8:4-13  —  [by  analysis]  - > 

(AND  [PLAY  ME  Cl]  [IN-SUIT  Cl  SO]) 

Here,  the  action  that  removes  a  card  in  suit  SO  from  player  ME's  hand  is  for  player  ME  to  play  a  card 
in  suit  SO. 


4.3.2.  Reformulating  an  Expression  to  Satisfy  the  Requirements  of  a  Method 


In  order  to  apply  an  operationalization  method  to  a  problem,  it  is  typically  necessary  to 
reformulate  the  problem  in  the  form  required  by  the  method.  This  may  involve  rephrasing  the 
overall  problem  to  match  the  general  problem  statement  for  the  problem,  or  reformulating  a 
component  of  the  problem  in  a  special  form  dictated  by  the  method. 


4.3.2. 1  Reformulating  an  Expression  to  Match  a  Method  Problem  Statement 


The  application  of  a  rule  expressing  an  operationalization  method  (§2)  is  often  preceded  by  one  or 
more  steps  that  transform  the  original  problem  into  a  form  that  matches  the  rule  (§1.6).  For  example, 
in  DTRIV4,  the  initial  expression  (QS-OUT)  is  reformulated  in  terms  of  set  membership  so  as  to 
match  the  pigeon-hole  rule  (§2.2): 


(OS-OUT) 


4:1 

---  [ELABORATE  by  RULE124]  ---> 

(OUT  QS) 

4:2 

---  [ELABORATE  by  RULE124]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  QS)) 

4:3 

(HAS  PI  QS) 

---  [ELA80RATE  by  RULE124]  ---> 

(AT  QS  (HAND  PI)) 

4:4 

---  [ELABORATE  by  RULE124]  ---> 

(=  (LOC  QS)  (HAND  PI)) 

4:5 

(EXISTS  PI  (OPPONENTS  ME)  (=  (LOC  QS)  (HAND 
---  [COLLECT  by  RULE  151]  ---> 

(EXISTS  Y 1  (PROJECT  HAND  (OPPONENTS  ME))  (= 

PI))) 

(LOC  QS)  Yl)) 

4:6 

---  [REMOVE-QUANT  by  RULE  162 ]  ---> 

(IN  (LOC  QS)  (PROJECT  HAND  (OPPONENTS  ME))) 

At  this  point  it  is  possible  to  apply  the  pigeon-hole  rule 
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RULE169:  (in  (f ...)  S)  ->  (not  (in  (f ...)  (diff  (range  0  S))) 


In  DERIV8,  the  expression  (VOID  PO  SO)  is  reformulated  in  terms  of  empty  sets: 

(ACHIEVE  (VOID  ME  SO)) 

8:1-2  —  [by  analysis]  — > 

(ACHIEVE  (EMPTY  (SET-OP  Cl  (CARDS- IN-HAND  ME) 

(IN-SUIT  Cl  SO)))) 


This  makes  it  possible  to  apply  the  set  depiction  rule  (§2.5): 

RUI.E6:  (achieve  (empty  S))  ->  (until  (empty  S)  (achieve  ( remove- 1- from  S))) 


In  DER1V3,  the  goal  (SUBSET  (LEGALCAROS  (OS  0))  (SET  QS ))  is  mapped  onto  RULF.6: 

(ACHIEVE  (SUBSET  (LEGALCARDS  (QSO) )  (SET  QS))) 

3:1-2  —  [by  analysis]  — > 

(ACHIEVE  (EMPTY  (DIPT  (LEGALCARDS  (QSO))  (SET  QS)))) 


In  DERIV2,  the  goal  (AVOID-TAKING-POINTS  (TRICK))  is  reformulated  as  a  predicate  on  a 
scenario  so  as  to  match  the  problem  statement  for  HSM  (§3.3): 

(AVOID-TAKING-POINTS  (TRICK)) 

2:1-2  -  [by  analysis]  - > 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 

Note  that  the  partial- matching  strategy  described  earlier  for  detecting  potential  applicability  of 
methods  (§4.2.2.1)  would  not  work  very  well  in  any  of  tire  above  examples.  In  most  of  them,  the 
initial  expression  (f ...)  requires  top-level  reformulation  to  fit  the  method.  The  only  exceptions  above 
involve  reformulating  expressions  of  the  form  (achieve  P)  to  fit  RULE6,  but  partial  matches  such  as 
the  one  between  (ACHIEVE  (VOID  ME  SO) )  and  (achieve  (empty  S))  are  very  weak  clues  since  any 
goal  (achieve  P)  would  match  just  as  well.  The  quality  of  the  match  might  be  enhanced  by 
introducing  suitable  features  like  "set-related  predicate"  as  a  common  generalization  of  VOID  and 
empty.  The  match  between  these  two  terms  would  be  considered  better  than  a  match  between  two 
totally  unrelated  terms.  This  would  help  distinguish  good  (highly  predictive)  matches  from  bad  ones. 
The  intersection  search  strategy  also  appears  useful  in  the  examples  above. 

4.3. 2.2  Reformulating  an  Expression  to  Provide  Information  for  a  Method 

An  expression  may  be  in  die  overall  form  required  by  an  operationalization  rule,  but  have  a 
component  in  the  wrong  form.  For  example,  consider  the  intersection  search  rule 

RULF.57:  (during  s  e)  ->  nil  if  s  and  e  have  no  common  sub-events 


§4.3.2.2.  Reformulating  an  Expression  to  Provide  Information  for  a  Method 
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RULE57  requires  tliat  s  and  e  be  expressed  in  terms  of  known  actions  like  GET-CARD,  rather  than 

specifications  of  their  effects  like  "cause  a  card  to  become  out"  or  'undo  a  void”.  This  requirement 

motivates  the  following  reformulation  of  the  abstract  event  “card  x  l  is  caused  to  be  out”  as  “some 

opponent  Pi  gets  card  XI”: 

(DURING  [ROUND- IN- PROGRESS] 

[CAUSE  (OUT  XI)]) 

10:5  ---  [ELABORATE  by  RULE124]  ---> 

[CAUSE  (EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  XI))] 

10:6  ---  [by  RULE329]  ---> 

[EXISTS  PI  (OPPONENTS  ME)  (CAUSE  (HAS  PI  XI))] 

(HAS  PI  XI) 

10:7  ---  [by  RULE124]  ---> 

(AT  XI  (HAND  PI)) 

(CAUSE  (AT  XI  (HAND  PI))) 

10:8  ---  [RECOGNIZE  by  RULE358]  ---> 

(MOVE  XI  LOCI  (HANO  PI)) 

10:9  ---  [RECOGNIZE  by  RULE  123]  ---> 

(DURING  [ROUND-IN-PROGRESS] 

[EXISTS  PI  (OPPONENTS  ME)  (GET-CARD  PI  XI  LOCI)]) 


The  reformulated  expression  can  now  be  used  as  die  value  of  c  in  RULE57,  since  it  is  expressed  in 

terms  of  die  known  action  GET -CARD.  Similarly,  in  DHR1V12,  the  abstract  event  “player  P0  ceases  to 

be  void  in  suit  SO"  is  reformulated  as  ”P0  gets  a  card  in  suit  SO”: 

(DURING  [ROUND-IN-PROGRESS] 

[UNDO  (VOID  P0  SO)]) 

12:2  ---  [ELABORATE  by  RULE  124]  ---> 

[UNDO  (NOT  (EXISTS  Cl  ( CARDS- IN-HAND  PO) 

(IN-SUIT  Cl  SO)))] 

12:3  ---  [RECOGNIZE  by  RULE377 ]  ---> 

[CAUSE  (EXISTS  Cl  ( CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO))] 

( CARDS- IN-HAND  PO) 

12:4  ---  [ELABORATE  by  RULE124]  ---> 

,  (SET-OF  C2  (CARDS)  (HAS  PO  C2 ) ) 

(EXISTS  Cl  (SET-OF  C2  (CARDS)  (HAS  PO  C2)) 

(IN-SUIT  Cl  SO)) 

12:5  ---  [by  RULE135]  ---> 

[CAUSE  (EXISTS  Cl  (CAROS)  (AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO]))] 

12:6  ---  [by  RULE329]  ---> 

[EXISTS  Cl  (CARDS)  (CAUSE  (AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO]))] 

(CAUSE  (AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO])) 

12:7  .  ---  [REDUCE  by  RULE35]  ---> 

(AND  [CAUSE  (HAS  PO  Cl)] 

[IN-SUIT  Cl  SO]) 
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(HAS  P0  Cl) 

12:8  ---  [by  RULE  124]  ---> 

(AT  Cl  (HAND  PO)) 

(CAUSE  (AT  Cl  (HANO  PO))) 

12:9  ---  [RECOGNIZE  by  RULE358]  ---> 

(MOVE  Cl  LOCI  (HAND  PO)) 

12:10  ---  [RECOGNIZE  by  RULE123]  ---> 

(DURING  [ROUNO- IN -PROGRESS] 

[EXISTS  Cl  (CAROS)  (AND  [GET-CARD  PO  Cl  LOCI] 

[IN-SUIT  Cl  SO])]) 


As  before,  the  reformulated  expression  can  subsequently  be  used  as  the  value  of  e  in  RULF.57, 
since  it  is  expressed  in  terms  of  the  known  action  GET -CARD. 


4.4.  Reformulation:  Summary 

A  variety  of  reformulation  problems  appear  in  the  derivations.  Some  are  represented  explicitly, 
while  others  are  implicit  in  the  directionality  of  a  derivation.  This  is  not  an  inherent  distinction 
between  two  kinds  of  reformulation  problems,  but  rather  an  artifact  of  1 00‘s  particular  set  of  rules 
and  the  absence  of  a  problem-solving  component:  explicit  representation  of  a  reformulation  problem 
requires  some  target  description  of  what  the  initial  expression  is  to  be  reformulated  as,  and  TOO  lacks 
the  sort  of  means-end  analysis  that  might  propose  such  targets  (§S.1.1).  Exceptions  --  explicit 
reformulation  problems  -  occur  when  the  decision  to  apply  a  particular  strategy,  encoded  in  a  rule, 
entails  solv  ing  a  particular  reformulation  problem.  For  example,  the  decision  to  use  HSM  to  evaluate 
a  predicate  generates  the  subproblcm  of  reformulating  the  predicate  as  a  function  of  the  choice 
sequence  (§3.3.3). 

Reformulation  problems  implicit  in  the  existing  derivations  could  be  explicitly  generated  by 
encoding  the  underlying  strategics  as  rules: 

Reformulate  a  goal  as  a  computable  predicate  on  a  choice  variable. 

Reformulate  an  expression  in  terms  of  an  observable  action  or  condition. 

Adding  such  rules  to  LOO  would  involve  enriching  the  rule  language  to  include  concepts  like 
"choice  variable"  and  "observable"  and  supplying  procedures  to  identify  instances  of  them.  c.g..  find 
all  the  choice  variables  in  a  given  task  description.  This  is  closely  related  to  the  problem  of 
representing  the  run-time  capabilities  of  the  task  agent  (§3.1.1). 


Since  the  implicit/explicit  distinction  depends  on  what  happens  to  be  implemented  in  TOO.  rather 
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than  on  inherent  problem  features,  it  provides  a  rather  uniformative  criterion  for  classifying 
reformulation  problems.  Better  criteria  include: 

Target  description:  reformulate  expression  e 

in  terms  of  concept  f 
as  a  function  of  quantity  e’ 

Accuracy:  reformulated  expression 

is  semantically  equivalent  to  the  original  expression 
approximates  the  original  expression 

Purpose :  transform  the  expression  to  fit 

the  run-time  capabilities  of  the  task  agent 
the  problem  statement  of  a  method 

These  criteria  provide  a  taxonomy  of  reformulation  problems: 

1.  Reformulate  expression  e  in  terms  of  concept  f:  solve  e  =  h(([xI . xj)  for  //,  .x; . xn 

a.  Fit  the  runtime  capabilities  of  the  task  agent 

i.  Reformulate  e  in  terms  of  an  observable  entity 

1.  Reformulate  e  in  terms  of  an  observable  condition 

2.  Reformulate  e  in  terms  of  an  observable  action 

3.  Reformulate  e  in  terms  of  an  object’s  observable  state 

b.  Reformulate  e  in  terms  of an  executable  action 

c.  Fit  die  requirements  of  a  method 

i.  Reformulate  e  to  match  the  problem  statement  of  a  method 

ii.  Reformulate  an  argument  of  e  to  satisfy  a  condition  of  the  method 

2.  Rcparamcterizc  expression  e  as  a  function  of  quantity  e':  solve  e  =  h(t)  for  h 

a.  Fit  the  runtime  capabilities  of  the  task  agent 

i.  Reformulate  a  goal  as  a  function  of  a  choice  variable 
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3.  Approximate  expression  e  as  a  0-th  order  function  of  quantity  v:  (function-of  v  (Dy  e)) 
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Chapter  5 
Analysis  Methods 

The  preceding  chapters  described  various  methods  for  operationalizing  expressions.  The  Riles 
expressing  these  methods  are  ''high-level"  in  that  they  make  operationalization  decisions  but  do  not 
carry  out  the  work  of  implementing  them.  In  particular,  they  do  not  tell  how  to: 

1.  Reformulate  the  original  problem  to  fit  the  Rile. 

2.  Verify  the  rule  condition. 

3.  Convea  the  result  of  applying  the  Rile  into  a  useful  form. 

The  broad  term  "analysis"  includes  all  three  of  these  processes,  which  account  for  the  bulk  of  the 
derivations  and  the  majority  of  the  rules  in  FOQ.  This  chapter  describes  the  methods  used  to  perform 
such  analysis: 

L.  Simplification  (§5.2) 

2.  Partial  matching  (§5.3) 

3.  Techniques  for  propagating  assumptions,  solving  for  variables,  and  finding  examples  (§5.4) 

4.  Fxpansion  of  recursive  definitions  (§5.5) 

5.  Intersection  search  (§5.6) 

6.  Problem  separation  (§5.7) 

7.  Translation  (§5.8) 

8.  Problem  reduction  (§5.9) 

9.  Problem  restructuring  (§5.10) 
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5.1.  Taxonomy  of  Analysis  Methods 

These  methods  fit  into  a  rough  taxonomy  based  on  how  they  are  used.  ;. e. .  the  syntactic  and 
semantic  effects  of  apply  ing  them: 

1.  Methods  that  presen e  semantic  equivalence 

a.  Methods  always  safe  to  use  (so  never  require  backtracking)  (§5.2) 

i.  Simplification  to  a  constant  (§5.2) 

1.  Systematic  evaluation  (§5.2.2) 

2.  Opportunistic  evaluation  (§5.2.3) 

ii.  Simplification  to  a  non-constant  (§5.2.4) 

b.  Heuristic  methods  (not  always  useful  even  though  valid) 

i.  Translation  (§5.8) 

1.  Elaboration  (§5.8.2) 

a.  Expand  recursive  definition  (§5.5) 

2.  Recognition  (§5.8.3) 

3.  Rephrasing  (§5.8.4) 

ii.  Intersection  search  (§5.6) 

2.  Methods  that  sometimes  violate  semantic  equivalence 

a.  Problem  reduction  (§5.9) 

i.  Partial  matching  (§5.3) 

1.  Solve  recurrence  (§5.3.5) 

ii.  Find  example  (§5.4.4) 

b.  Restructuring  (§5.10)  (transpose  (§5.10.1).  transfer  (§5.10.2).  functionalize  (§5.10.3)) 

i.  Problem  separation  (§5.7)  (split  (§5.7.4)  and  propagate  (§57.5)) 

1.  Case  analysis  (§5.7.1) 

2.  Condition  factoring  (§5.7.2) 

3.  Conjunctive  subgoaliug  (§5.7.3) 


ii.  Merge  problems  (§5.7.6) 
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c.  Propagate  information  (§5.4) 

i.  Use  assumption  (§5.4.3) 

ii.  Bind  satiable  (§5.4.1) 

iii.  Restrict  variable  (§5.4.2) 


5.2.  Simplification 

The  purpose  of  simplification  is  to  convert  an  expression  into  a  quasi-canenical  form  to  enable  the 
subsequent  application  of  operationalization  or  analysis  methods.  Simplification  rules  are 
characterized  by  the  following  properties: 

1.  The  nesv  expression  is  semantically  equ; valent  to  the  old  one,  Le.,  has  the  same  denotation. 

2.  The  new  expression  is  simpler  according  to  some  criterion  of  relative  complexity. 

3.  The  new  expression  can  be  operationalized  in  no  more  steps  than  the  old  one. 

Property  (1)  excludes  transformation  rules  that  sometimes  produce  an  expression  whose  meaning 
differs  from  the  original  expression,  such  as 

RULE43:  (R  [f e^ ...  cj  [f  ex’ ...  en'])  ->  (and  (=  Cj  e1']  ...  [=  en  en'])  if  R  is  reflexive 

The  complexity  criterion  of  property  (2)  may  depend  not  only  on  the  size  of  an  expression  but  on 
the  number  of  function  calls  in  it.  For  example,  the  transformation  from  the  intensiona!  expression 
(SET-OF  I  (LB:UB  l  100)  (IS-PRIME  I ))  to  its  extension  (SET  2  3  5  ...  97)  could  be 
considered  simplification,  even  though  the  latter  expression  contains  more  symbols. 

Property  (3)  says  that  simplification  is  always  a  good  idea,  or  at  least  never  hurts.  This  property  is 
extrinsic ,  since  it  depends  not  only  on  the  old  and  new  expressions  but  on  the  set  of 
operationalization  and  analysis  methods  available.  Fsscnually,  every  useful  method  that  applies  to 
the  original  expression  should  apply  to  the  simplified  one  as  well  (except  perhaps  for  the  methods 
used  to  make  the  simplification  itself.  Thus  not  every  transformation  of  an  expression  into  a  shorter 
semantic  equivalent  constitutes  simplification.  For  example,  recognizing  an  expression  as  an  instance 
o’f  a  known  concept  is  not  simplification,  since  useful  transformations  that  apply  to  the  expanded 
form  of  the  expression  may  not  apply  to  the  compact  form. 

An  example  of  simplification  is  deleting  a  null  clause  from  a  disjunction: 

(orP.  ...  nil ...  Pa) ->  (or  Pj ...  Pn) 
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This  may  be  a  waste  of  time  --  for  instance,  if  Pj  is  known  to  be  true,  it  just  delays  the 
transformation 

(or  T  P2 ...  nil ...  Pn)  ->  T 

However,  deleting  the  null  clause  is  harmless  in  that  any  useful  transformations  that  can  be  applied 
to  (or  Pj ...  nil ...  P  )  can  still  be  applied  to  (or  P^ ...  P  ).  in  particular  the  transformation 

(or  T  P2  ...  Pn)  ->  T 

It  is  convenient  to  distinguish  between  three  kinds  of  simplification  rules: 

1.  Systematic  evaluation  (§5.2.2) 

2.  Opportunistic  evaluation  (§5.2.3) 

3.  Simplification  to  a  non-constant  (§5.2.4) 

These  three  kinds  of  simplification  rules  are  distinguished  as  follows.  Evaluation  transforms  an 
expression  into  a  constant.  Systematic  evaluation  of  an  expression  (f  e2  ...  e  )  is  performed  by  a 
uniform  procedure  for  f  that  computes  the  value  of  (f  ...  en)  given  the  values  of  e^  ....  cn,  te., 

evaluates  any  expression  (f  c2 ...  cn)  where  c2 . cn  are  constants.  In  contrast,  opportunistic  evaluation 

computes  the  value  of  (f  Cj  ...  en)  by  means  of  a  special-case  rule  that  allows  non-constants  as  e2 . en 

but  only  works  for  expressions  that  fit  the  rule.  Finally,  simplification  to  a  nan-constant  reduces 
( f  ...  cn)  to  a  simpler  expression  without  computing  its  value.  (§5.2.1)  illustrates  these  classes  by 
example.  (§5.2.2),  I §5.2.3),  and  (§5.2.4)  list  the  rules  in  each  class,  and  (§5.2.6)  summarizes  the 
differences  between  them. 

5.2.1.  An  Illustrative  Example  of  Simplification 

An  example  drawn  from  DERIV3  illustrates  the  concepts  of  systematic  evaluation,  opportunistic 
evaluation,  and  simplification  to  a  non-constant,  and  their  role  in  operationalization.  Prior  to  the 
point  where  the  example  begins,  the  initial  goal  (“flush  out  the  Queen  of  spades  ')  has  been  split  into 
two  subgoals: 

(ACHIEVE  (FLUSH  QS ) ) 

3:1-12  —  [by  analysis]  — > 

(ACHIEVE  (AND  [SUBSET  (LEGALCAROS  (Q SO})  (SET  QS)] 

[SUBSET  (SET  QS)  (LEGAICAROS  (QSO))])) 

The  first  subgoal  means  “make  player  (QSO)  have  no  legal  cards  other  than  the  Queen  of  spades.'' 
The  second  subgoal  reduces  to  “make  it  legal  for  the  player  (QSO)  who  has  the  queen  of  spades  to 
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3:14-19  —  [by  analysis]  — > 

(LEGAL  (QSO)  QS ) 

3:20  ---  [ELABORATE  by  RULE  124 ]  ---> 

(AND  [HAS  (QSO)  QS] 

[=>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 
[NEQ  (SUIT-OF  QS)  H])] 

[=>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 
[IN-SUIT  QS  (SUIT-LED)])]) 


The  first  of  the  three  conjuncts  reduces  to  true  by  definition  of  (QSO);  the  third  is  satisfied  by 
assuming  that  spades  arc  led.  The  treatment  of  the  second  conjunct  illustrates  the  role  of  the 
transformations  discussed  in  this  section.  The  point  of  the  example  is  that  this  expression  can’t  be 
evaluated  systematically  without  knowing  whether  it's  legal  for  player  (QSO)  to  lead  hearts,  but  it  can 
still  be  evaluated  opportunistically,  and  doing  so  ultimately  enables  the  top-level  goal  to  be  simplified 
to  the  point  where  a  high-level  strategy  can  be  applied. 


First  (SUIT-OF  QS)  is  evaluated  as  S  (spades)  by  a  "fact  rule"  (RUI.E2)  that  simulates  a 
procedural  definition  of  SUIT -OF  or  a  general  mechanism  for  retrieving  properties  of  multi- featured 
objects  (in  this  case  the  suit  of  a  card): 

(SUIT-OF  QS) 

3:30  ---  [EVAL  by  RULE2]  ---> 

S 


An  expression  with  a  known  function  and  constant  arguments  can  be  systematically  evaluated: 

(NEQ  S  H) 

3:31  ---  [COMPUTE  by  RULE236]  ---> 

T 


A  disjunction  containing  a  term  know  n  to  be  true  can  be  opportunistically  evaluated  as  true  without 
know  ing  the  values  of  the  other  terms: 

(OR  [CAN-LE AO-HE ARTS  (QSO)]  T) 

3:32  ---  [EVAL  by  RULE184]  ---> 

T 


Similarly,  an  implication  whose  consequent  is  true  can  be  opportunistically  evaluated  as  true 
regardless  of  the  antecedent: 

(=>  (LEADING  (QSO))  T) 

3:33  ---  [EVAL  by  RULE47]  ---> 

T 


An  alternative  approach  is  to  assume  that  player  (QSO)  won't  be  leading,  an^  use  the  opportunistic 


transformation 
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( =  >  nil  P)  ->  T 

The  subgoal  of  making  it  legal  for  player  (QSO)  to  play  the  Queen  has  now  been  reduced  to  true 

(assuming  that  spades  will  be  led).  This  permits  the  overall  goal  to  be  simplified: 

(ACHIEVE  ( ANO  [SU8SET  (LEGALCAROS  (QSO))  (SET  QS ) ]  T)) 

3:36  ---  [SIMPLIFY  by  RULE343 ]  ---> 

(ACHIEVE  (SUBSET  (LEGALCAROS  (QSO)}  (SET  QS))) 

The  simplified  goal  can  be  reformulated  based  on  a  set  identity: 

3:37  ---  [by  RULE4]  ---> 

(ACHIEVE  (EMPTY  (DIFF  (LEGALCAROS  (QSO))  (SET  QS)))) 

The  reformulated  goal  matches  the  left  side  of  the  set-depletion  rule  (§2.5): 

RULF.6:  (achieve  (empty  S))  ->  (until  P  (achieve  (removc-l-from  S))), 
where  P  is  the  original  goal 

To  make  a  set  empty,  remove  its  elements  one  at  a  time. 

The  simple  strategy  expressed  by  this  rule  provides  the  basis  for  the  plan  subsequently 
derived  (§2.5.1).  Note  that  the  simplification  at  step  3 : 36  puts  the  overall  goal  into  a  quasi-canonical 
form  that  allows  this  strategy  to  be  applied. 

The  moral  of  this  story  is  three- fold: 

1.  Systematic  evaluation  is  useful  when  applicable. 

2.  Opportunistic  evaluation  sometimes  succeeds  where  systematic  evaluation  would  either  fail  or 
require  more  work. 

3.  Simplification  helps  reduce  expressions  to  a  quasi-canonical  form  to  which  higher-level 
transformations  can  be  applied. 

The  rest  of  this  section  presents  FOO’s  rules  for  evaluation  and  simplification. 

5.2.2.  Systematic  Evaluation 

Clearly,  systematic  evaluation  is  the  most  powerful  type  of  analysis  --  when  it  is  possible.  FOO’s 
rule  for  systematic  evaluation  is 

RULE236:  (fc, ...  cfl)  ->  c, 

where  c  is  the  result  of  applying  the  evaluation  procedure  for  f  to  the  constants  c1 ...  cn 
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The  following  examples  illustrate  RULE236's  use: 

(ANO  T  T) 

2:51  —  [EVAL  by  RULE23G]  ---> 

T 

(NEQ  S  H) 

3:31  ---  [EVAL  by  RULE236]  ---> 

T 

(ANO  T  (AND  T)  T) 

3:57  ---  [EVAL  by  RULE236 ]  ---> 

(ANO  T  T  T) 

3:58  ---  [EVAL  by  RULE236]  — > 

T 

(NOT  T) 

3:76  ---  [EVAL  by  RULE236]  — -> 

NIL 

(NOT  NIL) 

3:85  ---  [EVAL  by  RULE236]  ---> 

T 

(0-  NIL) 

9:52  ---  [EVAL  by  RULE236]  *--> 

NIL 

( D+  NIL  (0-  INCREASING)) 

9:58  ---  [EVAL  by  RULE236]  ---> 

(0+  NIL  DECREASING) 

9:59  ---  [EVAL  by  RULE236]  ---> 
DECREASING 

(-  2  1) 

13:34  ---  [EVAL  by  RULE236]  ---> 

T 


There  arc  many  other  places  in  the  derivations  where  an  expression  (f  ...  en)  was  transformed 
into  a  constant,  but  RLTE-236  was  not  used  because: 

1.  It  was  not  possible  to  evaluate  one  or  more  of  the  arguments  c.\ 

2.  It  was  not  necessary  to  evaluate  all  the  arguments;  or 

3.  FOO  lacked  a  general  evaluation  procedure  for  the  function  f. 


5.2.3.  Opportunistic  Evaluation 


Spccial-case  opportunistic  rules  for  evaluating  an  expression  (f  c,  ...  c(i)  arc  useful  w'hen 

1.  It  is  not  possible  to  evaluate  one  or  more  of  the  arguments  e^ 

2.  The  expression  can  be  evaluated  without  evaluating  all  tire  arguments;  or 

3.  There  is  no  general  evaluation  procedure  available  for  the  function  f. 
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I'OO’s  opportunistic  evaluation  rules  are  listed  below  along  with  some  of  the  expressions  they  were 
used  to  evaluate.  For  brevity,  only  the  step  number  is  shown;  the  computed  value  of  the  expression 
is  given  by  the  right-hand  side  of  the  aile.  (The  rule  index  lists  all  uses  of  each  rule.)  The  following 
list  omits  ccitain  rules  that  produce  a  constant  but  are  more  appropriately  discussed  elsewhere,  e.g., 
under  intersection  search  (§5.6). 


RULE47:  (  =  >PT)->T 

3:28  (=>  (FOLLOWING  ( QSO ) )  T) 
3:33  (=>  (LEADING  (QSO))  T) 


RULF179:  (R  e  o)  ->  T  if  R  is  reflexive 
3:73  (*  S  S) 

5:33  (=  ( SUIT -OF  (CAR0-0F  ME))  (SUIT-OF  (CARD-OF  ME))) 
9:34  ( =  X2  X2) 

14:80  (=  (NEXT  NOTE)  (NEXT  NOTE)) 


RUI.EI84:  (or ...  T  ...)->  T 

3:27  (OR  [VOIO  (QSO)  (SUIT-LEO)]  T) 

3:32  (OR  [CAN- LEAD-HEARTS  (QSO)]  T) 

4:25  (OR  T 

[IN  (HAND  ME)  (PILES  (PLAYERS))] 

[IN  (HAND  ME)  (SET  DECK  POT  HOLE)]) 

RUI.E28S:  ( #  (collection  Cj ...  efl))  ->  n 

14:24  (#  (SET  (NEXT  NOTE))) 

RLT.F:S9:  (jflf  nil)  ->  0 

14:23  (4  NIL) 

RULE293:  (in(onc-ofS)S)->T 

14:33  (IN  (HIGHEST  CANTUS-1)  CANTUS-1) 

RULF337:  (subset  (prefix  S  i)  S)  ->T 

2:98  (SUBSET  (PREFIX  CARDS-PLAYED1  ANY)  CARDS -PLAYED1 ) 


5.2.4.  Simplification  to  a  Non-constant 

Sometimes  an  expression  can  be  simplified  but  not  evaluated.  By  reducing  an  expression  to  a 
quasi-canonical  form,  such  simplification  may  enable  (and  at  worst  does  not  prevent)  the  application 
of  useful  rules.  FOO's  rules  for  this  kind  of  simplification  appear  below,  together  with  some  of  the 
expressions  they  were  used  to  simplify.  For  brevity,  the  resulting  expression  is  only  shown  for  the 
first  example  of  each  rule.  The  examples  arc  included  to  clarify  each  rule's  operation  and  the  variety 
of  expressions  to  which  it  applies,  but  are  not  very  interesting  reading. 
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RULEil:  (and  \\  ...  T ...  PJ  ->  (and  Pt ...  Pn) 

2:33-34  (ANO  [IN  P4  (OPPONENTS  ME)]  T  T) 

--->  (AND  [IN  P4  (OPPONENTS  ME)]) 

2:53  (ANO  T  [IN-SUIT  Cll  (SUIT-LED)]) 

2:60  (AND  T  [LAMBDA  (PI  C21)  ...]) 

3:82  (ANO  [PLAY  (QSO)  C3]  T  [»>  (FOLLOWING  (QSO))  ...]  [IN  C3  ...]) 
RULE12:  (=>TP)->P 

3:86  (=>  T  (IN-SUIT  C3  S))  --->  (IN-SUIT  C3  S) 

13:26  (=>  T  (FORALL  INTERVAL1  ( INTERVALS-OF  PROJECT1) 

(USABLE- INTERVAL!  INTERVAL1 ) ) ) 

13:50  (=>  T  (=<  (RANGE  PROJECT1)  (MAJOR  10))) 

RULE19:  (diff  (join  S(  ...  S  ...  Sn)  S)  ->  Qoin  Sj  ...  Sfl)  if  S, . S . Sn  arc  mutually  disjoint 

4:16  (DIFF  (UNION  [HANDS  (PLAYERS)] 

[PILES  (PLAYERS)] 

[SET  DECK  POT  HOLE]) 

(HANDS  (PLAYERS))) 

--->  (UNION  [PILES  (PLAYERS)]  [SET  DECK  POT  HOLE]) 

RULE88:  (not  (not  P))  •>  P 

2:43  (NOT  (NOT  (EXISTS  Cl  (CAROS- IN-HAND  P5  (IN-SUIT  Cl  (SUIT-LED) ) ) ) ) ) 
--->  (EXISTS  Cl  (CARDS- IN-HAND  P5  (IN-SUIT  Cl  (SUIT-LED)))) 

5:38  (NOT  (NOT  (HIGHER  (FIND-ELT  (CARDS- IN-SUIT -LED  (CARDS-PLAYED) ) ) 

(CARD-OF  ME)))) 


RUI.H108:  (Q  x  S  (and  ...  P  ...))  ->  (and  P  [Q  x  S  (and  ...)])  if  P  is  independent  of  x, 
assuming  S  is  non-empty 

6:13  (EXISTS  C3  (CARDS-PLAYED)  (AND  [IN  C3  ( PO INT -CARDS ) ] 

[-  (TRICK-WINNER)  ME])) 

--->  (AND  [=  (TRICK-WINNER)  ME] 

[EXISTS  C3  (AND  [IN  C3  (POINT-CARDS)])]) 

RUI.E155:  (Q  x  S  P)  ->  P  if  P  is  independent  of  x.  assuming  S  is  non-empty 

2:56  (EXISTS  Cll  (CAROS)  (IN-SUIT  C2  (SUIT-LED))) 

--->  (IN-SUIT  C2  (SUIT-LED)) 

7:7  (FORALL  XI  ( CARDS  -  IN -SUI T - LED  (CARDS-PLAYED)) 

(NOT  (LOW  (CARO-OF  ME)))) 

RULE176:  (join  et ...  nil ...  en)  ->  (join  ct ...  en) 

2:8  (APPEND  (CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))) 
NIL) 

-->  (APPEND  (CHOICE-SEQ-OF' (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)))) 


3:78  (OR  NIL  [IN-SUIT  C3  S]) 
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4:39  (OR  NIL  [AT  QS  POT] 

[AT  QS  HOLE] 

[AT  QS  (HAND  ME)] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 

4:49  (OR  [WAS-QURING  (CURRENT  ROUND- IN-PROGRESS) 

(CAUSE  (AT  QS  (PILE  P3)))] 

NIL) 

RULE177:  (C  Cj ...  (C  c,’  ...  ck') ...  en)  ->  (C  ^ ...  cn  e,' ...  ek'), 
where  C  is  a  commutative  operator  (eg.,  AND,  OR.  +,  UNION,  etc.) 

3:45  (AND  [AND  [UNDO  (HAS  (QSO)  C3)] 

[=>  (LEADING  (QSO))  . . .] 

[O  (FOLLOWING  (QSO))  .  .  .]] 

[IN  C3  (DIFF  (CARDS)  (SET  QS))]) 

--->  (AND  [UNDO  (HAS  (QSO)  C3)] 

[  =  >  (LEADING  (QSO))  .  .  .] 

[«>  (FOLLOWING  (QSO))  .  .  .] 

[IN  C3  (DIFF  (CARDS)  (SET  QS))]) 

4:28  (UNION  [UNION  [PILES  (PLAYERS)]  [SET  DECK  POT  HOLE]] 

[SET  (HAND  ME)]) 

4:33  (OR  [OR  [*  (LOC  QS)  DECK]  [  =  (LOC  QS)  POT]  [=  (LOC  QS)  HOLE]  . ..] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 

14:38  (AND  [NOT  (CHANGE  (CLIMAX  CANTUS-1))] 

[ANO  [=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]]) 

RUI.R178:  (C  c)  ->  e.  where  C  is  a  commutative  operator 

2:9  (APPEND  [CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))]) 

-->  (CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))) 

2:35  (AND  [IN  P4  (OPPONENTS  ME)]) 

2:61  (AND  [LAMBOA  ( CAROS- PLAYED1 )  . .  . ]) 

3:79  (OR  [IN-SUIT  C3  S]) 

9:46  (0+  [0*  (DEPENDENCE  ...)  (DEPENDENCE  ...)]) 

14:65  (UNION  [IF  (=  ...)  (SET  (NEXT  MOTE))  NIL]) 

RULE  185:  (if T  x  y) ->  x 

4:26  (IF  T  (SET  (HANO  ME))  NIL) 

--->  (SET  (HANO  ME)) 

14:67  (IF  T  (SET  (NEXT  NOTE))  NIL) 

♦ 

RUI.E1S8:  (C  ...  c  ...  e  ...)  ->  (C  ...  e  ...),  Le.,  remove  duplicate  occurrence  of  e, 
where  C  is  a  commutative  operator 

2:70  (ANO  [IN  ME  (INOICES-OF  CAROS-PLAYEO 1 )  ] 

[IN  ME  (  INOICES-OF  CARDS -PLAYED  1 )] ) 

--->  (ANO  [IN  ME  (INOICES-OF  CARDS-PLAYED1) ])  - 
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13:90  (AND  [IN  CLIMAX1  PR0JECT1] 

[=<  ( ^OCCURRENCES  CLIMAX1  PROJECT1)  1] 

[IN  CLIMAX1  PROJECT  1 ] 

[FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX1))] 

[FORALL  INTERVAL1  ( INTERVALS-Of  PR0JECT1) 
(USABLE-INTERVAL!  INTERVAL1)] 

[  =  <  (RANGE  PROJECT  1 )  (MAJOR  10)]) 

RULE216:  (f  ([inverse  f|  e))  ->  e 

9:19  (NOT  ([INVERSE  MOT]  (DISJOINT  ( CARDS- IN-HAND  P0)  SI))) 

--->  (DISJOINT  (CARDS- IN-HAND  P0)  SI) 

RULE253:  (!b:ub  k  k)  ->  {k} 

13:35  (LB-.UB  1  1)  --->  (SET  1) 

RULE255:  (Q  x  (collection  e)  Px)  ->  Pg 

2:104  (EXISTS  C23  (LIST  C21)  (HAS-POINTS  C23))  --->  (HAS-POINTS  C21) 

RULF.281:  (onc-of  (collection  e))  ->  e 

14:45  (HIGHEST  (LIST  (NEXT  NOTE)))  --->  (NEXT  NOTE) 

RULE310:  (apply  append  (each  x  S  (list  ex)))  ->  (each  x  S  Ex) 

2:13  (APPLY  APPEND  (EACH  PI  (PLAYERS) 

(LIST  (CHOOSE  (CARD-OF  PI)  (LEGALCARDS  PI) 
(PLAY  PI  (CARO-OF  PI)))))) 

--->  (EACH  PI  (PLAYERS)  (CHOOSE  (CARD-OF  PI)  (LEGALCARDS  PI) 

(PLAY  PI  (CARD-OF  PI)))) 

13:7  (APPLY  APPEND  (EACH  II  (LB : UB  1  (CANTUS-LENGTH ) ) 

(LIST  (CHOOSE  (NOTE  II)  (TONES)  (MOTE  II))))) 


RULE341:  (C  i  c)  ->  e,  where  C  is  a  commutative  operator  and  i  is  its  identity  element 

3:19  (ANO  T  [LEGAL  (QSO)  QS] )  --->  (LEGAL  (QSO)  QS) 

5:9  (OR  NIL  [DURING  (TAKE-TRICK  (TRICK-WINNER) )  (TAKE  ME  QS)]) 

9:48  (D*  INCREASING  [DEPENDENCE  (PR-DISJOINT-FORMULA  #H  #S  #U)  #S]) 
13:40  (ANO  T  [LAMBDA  (II  NOTE1)  ...]) 

RUI.E343:  (C  c  i)  ->  e,  where  C  is  a  commutative  operator  and  i  is  its  identity  element 

3:36  (AND  [SUBSET  (LEGALCARDS  (QSO))  (SET  QS)]  T) 

--->  (SUBSET  (LEGALCARDS  (QSO))  (SET  QS)) 

9:53  (0+  [OEPENOENCE  (^CHOOSE  (-  #U  *S)  #H)  #S]  NIL) 

14:26  (*  [^OCCURENCES  (CLIMAX  CANTUS-1)  CANTUS-1]  0) 
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5.2.5.  Automated  Simplification 

Simplification  does  not  hinder  die  subsequent  application  of  other  methods,  and  often  helps  by 
converting  expressions  into  a  quasi-canonical  form  that  fits  an  available  mcdiod.  FOO's  simplification  * 

rules  could  therefore  safely  be  incorporated  in  a  procedure  automatically  applied  after  each  step  in  a 
derivation.  This  would  change  the  basic  problem-solving  cycle  from  select-a- rule- and- apply- it 
(analogous  to  the  "recognize-act”  cycle  of  production  systems  [Newell  72])  to  select- apply- simplify. 

♦ 

The  latter  architecture  is  exemplified  by  programs  for  symbolic  integration  [Moses  71]  [Slagle  63]  and 
other  kinds  of  man  ipulation. 

Using  this  approach  in  an  operationalization  problem-solver  would  decrease  derivation  length,  Le., 
the  number  of  operators  needed  to  transform  a  problem  into  an  operational  solution.  Thus  the  depth 
of  die  search  space  would  be  reduced.  However,  the  decision  whedter  to  incorporate  a  given 
transformation  rule  in  the  canonicalization  procedure  would  have  to  be  made  very  carefully,  since  it 
depends  not  only  on  the  rule  itself  but  also  on  its  potential  interference  with  other  mediods. 

Incorrectly  classifying  a  rule  as  a  simplification  rule  could  make  it  impossible  to  generate  a  non- 
canonica!  form  required  by  another  rule.  For  example,  consider 

RUI.E213:  ([lambda  (xt ...  x^)  e]  et ...  en)  ->e’, 

where  c‘  is  the  result  of  substituting  eA ...  e^  for  x} ...  xfl  throughout  e 

RULH213  is  useful  in  DERIV14: 

([LAMBDA  (J)  (NOTE  (+  J  1))]  Tl) 

;1:36  ---  [SIMPLIFY  by  RULE213]  ---> 

(NOTE  (+  Tl  1)) 

However,  RULE213  can  interfere  with  a  rule  for  instantiating  the  l  ISM  schema  (§3.3.3): 

RULE317:  (HSM  with  (rcformulatcd-problem  :  ([lambda  (s)  PJ  choices))) 

->  (HSM  with  (solution-test :  (lambda  (s)  Ps)) ...) 

Specifically,  applying  RULE213  whenever  possible  would  automatically  reduce  any  expression  of 
the  form  ([lambda  (s)  1’.]  choices)  to  PchojcM.  preventing  the  application  of  RULE317. 
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5.2.6.  Simplification:  Summary 

Simplification  transforms  an  expression  into  a  simpler  but  semantically  equivalent  one.  FOO  has 
three  kinds  of  simplification  rules: 

1.  Systematic  evaluation  transfonns  an  expression  (f  Cj  ...  cn)  into  a  constant  by  apply  ing  a  uniform 

evaluation  procedure  for  f  to  the  constant  arguments  Cj . cn. 

2.  Opportunistic  evaluation  uses  a  special-case  rule  to  transform  an  expression  into  a  constant 
w  ithout  evaluating  its  arguments. 

3.  Simplification  to  a  non-constant  transforms  an  expression  into  a  quasi-canonical  form  to  which 
additional  methods  may  apply. 

Simplification  preserves  semantic  equivalence  and  typically  requires  little  computation.  It  does 
not  hinder  the  subsequent  application  of  other  methods,  and  often  helps  by  converting  expressions 
into  a  quasi-canonical  form  that  fits  an  available  method,  foo's  simplification  rules  could  therefore 
safely  be  incorporated  in  a  canonicali/ation  procedure  automatically  applied  after  each  step  in  a 
derivation,  although  the  decision  to  classify  a  rule  as  a  simplification  rule  -•  i.e..  to  apply  it  whenever 
possible  -  wuuld  depend  not  only  on  the  rule  itself  but  also  on  the  other  rules  available,  so  as  not  to 
interfere  with  them.  Incorrectly  classifying  a  rule  as  a  simplification  rule  could  interfere  with  the 
transformation  of  expressions  into  a  non-canonical  form  required  by  some  other  rule. 


5.3.  Partial  Matching 

TOO  uses  partial  matching  [Hayes-Roth  "Sb]  to  simplify  a  relation  between  similar  expressions  by 
equating  their  corresponding  arguments.  Unlike  the  methods  described  in  (§5.2).  partial  matching  is 
generally  sound  but  not  always  valid.  It  can  be  used  to  make  plausible  inferences  th.it  are  logically 
unjustified  but  empirically  true,  or  at  least  load  to  good  task  performance.  Partial  matching  permits 
analysis  of  an  expression  without  expanding  the  definitions  of  all  die  terms  in  it.  This  is  especially 
useful  if  the  expression  contains  terms  whose  definitions  are  unknown. 

ITie  rest  of  this  section  is  organized  as  follows.  (§5.3.1)  describes  the  typical  scenario  surrounding 
the  use  of  partial  matching.  (§5.3.2)  illustrates  diis  scenario  by  means  of  an  example.  (§5.3.3) 
discusses  the  logical  status  of  the  partial  matching  transformation.  (§5.3.4)  presents  roo's  rules  for 
partial  matching.  (§5.3.5)  describes  the  use  of  partial  matching  to  induce  function  definitions  from 
recurrence  equations.  Finally,  (§5.3.6)  summarizes  the  purpose,  use,  and  result  of  partial  matching. 
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5.3.1.  A  General  Scenario  for  Partial  Matching 

Partial  matching  in  100  is  typically  used  to  reduce  a  proposition  (R  [f  Oj  ...  ej  [f  ...  en]),  where 

R  is  a  reflexive  binary  relation,  to  the  assertion  that  e(  =  e.‘  for  each  i  =  1 . n.  It  usually  occurs  as 

part  of  the  follow  ing  partial  matching  scenario: 

1.  Reformulate  an  expression  in  terms  of  a  relation  between  two  entities  of  the  same  type. 

2.  Translate  the  descriptions  of  these  entities  into  common  terms. 

3.  Restructure  the  expression  to  make  the  arguments  of  the  relation  have  the  same  form. 

4.  Partial-match  die  arguments  by  equating  their  corresponding  components. 

5.  Simplify  die  resulting  conjunction  of  equalities  in  its  surrounding  context. 

The  first  three  steps  satisfy  requirements  of  the  partial  matching  method: 

Reformulating  die  initial  expression  provides  the  relation  R. 

Translating  its  arguments  into  common  terms  provides  the  function  f. 

Restructuring  die  expression  provides  the  required  form  (R  (f ...]  (f ...)). 

The  fourdi  step  makes  the  expression  more  nearly  operational: 

Partial-matching  die  arguments  eliminates  the  possibly  troublesome  R  and  f. 

The  last  step  satisfies  requirements  of  subsequently  applied  methods: 

Simplifying  the  expression  puts  it  in  a  quasi-canonical  form. 

When  one  of  these  requirements  is  satisfied  sercndipitously .  the  corresponding  step  is  absent. 

5.3.2.  An  Example  of  Partial  Matching 

An  excerpt  from  DF.RIV6  illustrates  the  usefulness  of  partial  matching.  To  operationalize  the 

advice  "avoid  taking  points  during  the  trick,"  the  definition  of  a  trick  is  analyzed  to  determine  die 

circumstances  under  which  player  ME  takes  points: 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

6:2-6  —  [by  analysis]  — > 

(ACHIEVE  ( NOT  (DURING  [TAKE-TRICK  (TRICK-WINNER)] 

[TAKE-POINTS  ME]))) 


In  other  words,  to  avoid  caking  points,  make  sure  you  don't  take  any  point  cards  when  the  winner 


§5.3.2.  An  Example  of  Partial  Matching 


207 


takes  the  trick.  In  terms  of  the  partial-matching  scene  ;o,  this  reformulates  the  problem  in  terms  of 

the  relation  DURING  between  the  event  descriptions  (TAKE-TRICK  (TRICK-WINNER))  and 

(TAKE-POINTS  ME),  which  are  next  translated  into  common  terms: 

(DURING  [TAKE-TRICK  (TRICK-WINNER)] 

[TAKE-POINTS  ME]) 

6:7-8  ---  [ELABORATE  by  RULE  124]  ---> 

(DURING  [EACH  C3  ( CARDS- PLAYED ) 

(TAKE  (TRICK-WINNER)  C3)] 

[FOR-SOME  Cl  (POINT-CARDS) 

(TAKE  ME  Cl)]))) 


In  this  ease,  the  “common  term''  is  the  action  TAKE.  The  next  step  restructures  the  expression  into 

die  form  (DURING  [TAKE  ...]  [TAKE  . ..])  by  moving  the  quantifiers  outside: 

(DURING  [EACH  C3  ( CARDS- PL AYED ) 

(TAKE  (TRICK-WINNER)  C3 ) ] 

[FOR-SOME  Cl  (POINT-CARDS) 

(TAKE  ME  Cl)]) 

6:9-10  ---  [by  RULE58 .  RULE100]  ---> 

(EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(DURING  [TAKE  (TRICK-WINNER)  C3] 

[TAKE  ME  Cl]))) 


Now  that  both  arguments  to  DURING  have  the  form  (take  <pl&yt;r>  <carci>),  they  can  be 

partial-matched  by  equating  their  corresponding  components: 

(DURING  [TAKE  (TRICK-WINNER)  C3] 

[TAKE  ME  Cl]) 

6:11  ---  [by  RULE43]  ---> 

(AND  [  =  (TRICK-WINNER)  ME]  [=  C3  Cl]) 


This  transformation  eliminates  the  predicate  DURING,  for  which  I  oo  has  no  general  definition,  and 

the  action  TAKE,  whose  details  are  irrcvelant  to  the  problem  of  avoiding  points.  The  resulting 

expression  is  simplified  by  using  the  equality  («  C3  Ci)  to  eliminate  the  quantifier  variable  Cl: 

*  (EXISTS  C3  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(AND  [=  (TRICK-WINNER)  ME]  [  =  C3  Cl]))) 

6:12  ---  [REMOVE-QUANT  by  RULE59]  ---> 

(EXISTS  C3  (CARDS-PLAYED) 

(AND  [IN  C3  (POINT-CARDS)] 

[=  (TRICK-WINNER)  ME])) 


» 


The  conjunct  ( =  (TRICK- WINNER)  ME)  can  be  moved  outside  the  scope  of  quantification: 
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(EXISTS  C3  (CARDS-PLAYED) 

(AND  [IN  C3  (POINT-CARDS)] 

[=  (TRICK-WINNER)  ME])) 

6:13-14  ---  [SIMPIIFY-QUANT  by  RULE  103 ,  RULE  178]  ---> 

(AND  [=  (TRICK-WINNER)  ME] 

[EXISTS  C3  (CARDS-PLAYED) 

(IN  C3  (POINT-CARDS))]) 


Further  analysis  leads  to  an  operational  solution: 

(ACHIEVE  ( HOT  (AND  [=  ( TR ICK-WI NNE R)  ME] 

[EXISTS  C3  (CARDS-PLAYED) 

(IN  C3  (POINT-CARDS))]) 

6:15-43  —  [by  analysis] - > 

(ACHIEVE  (=>  (AND  [IN-SUIT-LED  (CARD-OF  ME)]  [TR I CK- HAS -POINTS] ) 
(LOW  (CARD-OF  ME)))) 


That  is,  if  you're  following  suit  (or  leading)  in  a  trick  liable  to  have  points,  play  a  low  card  to  avoid 
taking  points. 


5.3.3.  Logical  Status  of  Partial  Matching 

The  key  transformation  in  the  example  was  performed  by  a  general  rule  for  partial  matching: 
RULF.43:  (R  [fe1 ...  en]  [fe^  ...  cn'l)  ->(and  [=  e^, ']...[=  cn  en’])  if  R  is  reflexive 

RL'I.F.43  is  obviously  a  logically  sufficient  transformation,  t.e„ 

e(  =  Cj’  for  i  =  1 . n  implies  (R  [f  c1 ...  ej  [f  c^  ...  cn’j)  if  R  is  retlexive 

I)ut  when  is  the  converse  true,  Le.,  vvhen  does  RUI.E43  preserve  logical  equivalence?  It  docs  in  the 
example:  (during  cvcnt^  event,)  implies  cvcn^  =  event,  if  the  two  events  are  instances  of  the  same 
action  (in  this  case  TAKE),  since: 

1.  The  simple  model  of  the  Hearts  world  assumes  that  primitive  actions  (like  moving  a  card)  occur 
in  sequence  rather  than  concurrently. 

2.  None  of  the  actions  in  the  Hearts  domain  is  denned  recursively,  so  one  instance  of  an  action 
can't  occur  as  a  proper  sub-event  of  another. 

These  two  properties  of  the  domain  -  or  more  precisely,  of  the  n ay  the  Jcnuin  is  »  odelleJ  by 
FOO's  knowledge  base  of  concept  definitions  --  can  be  clarified  by  showing  what  would  happen  if 
they  were  violated: 

1.  If  the  domain  model  allowed  two  cards  to  be  taken  simultaneously,  then  the  condition 
(DURING  [TAKE  ( TR  ICK-WI  NNER )  C3]  [TAKE  ME  Cl])  would  not  necessarily  imply 
C3  =  Cl. 
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2.  Suppose  taking  a  sequence  of  cards  were  defined  recursively  as 

TAKE-CARDS  =■ 

(LAMBDA  (PS) 

(=>  ( NOT  (EMPTY  S)) 

(SCENARIO 

(TAKE  P  (FIRST  S)) 

(TAKE-CARDS  P  (EXCEPT  (FIRST  S)  S))))) 

Then  (DURING  [TAKE-CARDS  (TRICK-WINNER)  SI]  [TAKE-CARDS  ME  S2] )  would  not 
necessarily  imply  Si  =  S2. 

In  short,  the  logical  status  of  the  partial  matching  transformation  may  depend  on  subtle  properties 
not  only  of  the  domain  but  of  the  way  in  which  it’s  modelled  in  the  knowledge  base,  and  may  in  fact 
be  quite  difficult  to  determine. 

[Ten  when  partial  matching  demonstrably  does  not  preserve  logical  equivalence,  it  can  still  be 

useful  to  use  it  as  though  it  did.  Consider,  for  example,  this  reduction  from  DHRIYU: 

(=>  [VOID  PI  (SUIT-LED)]  [VOID  P0  SO]) 

11:11  ---  [REDUCE  by  RULE43]  ---> 

(AND  [«  PI  PO]  [=  (SUIT-LED)  SO]) 

One  can  invent  game  situations  in  which  Pi's  being  void  in  tire  suit  led  implies  that  a  different 
player  PC  is  void  in  suit  SO.  Thus  the  new  expression  is  not  a  logically  necessary  condition  for  die 
original  one.  However,  it  is  a  heunstically  necessary  condition  in  the  sense  that  it  applies  to  all  but  a 
few  perverse  situations.  Thus  treating  partial  matching  as  an  equivalence-preserving  transformation 
may  be  logically  incorrect  but  empirically  valid.  /.<*..  lead  to  good  task  performance.  In  this  sense 
partial  matching  can  be  used  to  make  plausible  inferences  of  the  form  “if  relation  R  holds  between 
two  similar  expressions,  their  corresponding  arguments  are  equal." 

A  complete  operationalization  system  that  used  such  unproven  inferences  would  need  some 
mechanism  to  evaluate  their  empirical  validity  and  identify  incorrect  inferences  with  adverse  effects. 
A  proposed  mechanism  for  identifying  such  inferences  is  failure-driven  learning  (§8.1.7)  [Hayes-Roth 
3  ib).  The  idea  is  to  remember  the  inferences  made  in  the  course  of  deriving  plans  used  in 
performing  a  task.  When  a  plan  fails  to  achieve  its  stated  goal  in  a  particular  task  situation,  the  faulty 
inference  is  identified  by  evaluating  each  proposition  in  the  plan's  derivation  in  the  context  of  the 
specific  situation.  (This  is  much  easier  than  analyzing  die  general  logical  validity  of  each  inference  - 
essentially  theorem-proving.)  The  plan  is  then  corrected  to  avoid  similar  failures,  e.g..  by  suitably 
restricting  the  conditions  in  which  die  plan  is  used.  This  approach  focuses  attention  on  exactly  those 
incorrect  inferences  with  adverse  effects,  rather  dian  continously  monitoring  the  empirical  validity  of 
every  inference  made  during  operationalization. 


210 


§5.  Analysis  Methods 


5.3.4.  Partial  Matching  Rules 


R11.H43  is  only  one  of  several  partial  matching  rules  in  100:  it  reduces  relations  between 
expressions  based  on  n-ary  functions.  Other  rules  handle  expressions  involving  quantifiers  and  secs. 
The  rules  are  listed  below,  together  with  some  of  the  expressions  to  which  they  were  applied. 


RUI-KJO:  (R  If  S,|  (fS,l)  ->  T  if  (subset  S,  SO, 

where  f  is  monotonic  w.r.t.  partial-ordering  R.  i.c..  (R  |f  S)  [f  S'])  if  S  is  a  subset  of  S' 

13:23  (SU8SET  [INTERVALS-0 F  PROJECTl] 

[INTERVALS-OF  (PROJECT  NOTE  ( LB  :  UB  1  ( CANTUS  -  LENGTH )))]  ) 

- >  T 

since  ( SU8SET  PR0JECT1  (PROJECT  NOTE  ( L8  :  UB  1  ( CANTUS - LENG TH  ))) ) 

13:46  (=<  [RANGE  PROJECTt] 

[RANGE  (PROJECT  NOTE  (L8:UB  1  ( CANTUS -l ENGT H )))]  ) 

- >  T 

Since  (SUBSET  PR0JECT1  (PROJECT  NOTE  ( LB : UB  1  ( CANTUS - LE NG T H ))) ) 

13:96  (*<  [*f  (SET-OF  X3  PROJECTl  (=  X3  CLIMAX1))] 

[#  (SET-OF  X4  (PROJECT  NOTE  (LB.UB  I  ( CANTUS -LENGTH )) ) 

(=  X4  CLIMAX1))]) 

- >  T 

Since  (SUBSET  [SET-OF  X3  PROJECTl  (=  X3  CLIMAX1)] 

[SET-OF  X  4  (PROJECT  NOTE  ( LB : UB  1  ( CANT  US -LE NOTH  ))  ) 

(=  X4  CLIMAX!)]) 

RL'l  t£43:  (R  [f  e( ...  eul  [fc^  ...  cn  ])  ->  (and  {=  e(  c('J ...  [=  en  en  |)  if  R  is  reflexive 

3:52  (=>  [MOVE  C4  (HANO  PI)  POT]  [MOVE  C3  (HANO  (QSO))  L0C3]) 

--->  (AND  [=  C4  C3]  [*  (HANO  PI)  (HAND  (QSO))]  [-  POT  LOCJ]) 

3:55  (=  [HAND  PI]  [HAND  (QSO)]) 

--->  (AND  [=  PI  (QSO)]) 

5:12  (DURING  [TAKE  ( TR I CK- W I NNE R )  Cl]  [TAKE  ME  QS]) 

--->  (AND  [=  (TRICK-WINNER)  ME]  [=  Cl  QS]) 

RUI  K91:  (R[fel...cn|[fcl'...cn'|)->Tif(and(=  e,cl']...[  =  cncn'p. 
where  R  is  reflexive 


RUI.H91  resembles  RULK43  but  explicitly  treats  die  conjoined  equalities  as  a  sufficient  condition. 

2:48  (=>  [HAS  PI  C2]  [HAS  P5  Cll]) 

--->  T 

Since  (ANO  [=  PI  P5]  [=  C2  Cll]) 

2:62  (=>  [=  ((PROJECT  CARD-OF  (PLAYERS))  ME) 

(HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS)))] 

[=  (CARDS-PLAYED1  ME)  ( HIGHES T- IN-SU I T -LED  C ARDS  -  PLAYED  1 )] ) 

--->  T 

Since  (ANO  [=  ((PROJECT  CARO-OF  (PLAYERS))  ME)  ( CARDS-PLAYED1  ME)] 

[*  ( HIGHEST -IN-SUIT-LEO  (PROJECT  CARD-OF  (PLAYERS))) 

(HIGHEST- IN-SU IT-LEO  CAROS  -  PLAYED  1 ) ] 
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6:54  (=  [SUIT-OF  DK]  [SUIT-OF  (CARD-OF  (LEADER))]) 

—  >  T 

Since  (AMO  [=  OK  (CARD-OF  (LEADER))]) 

RULE172:  (in  (fe)  (project  f  S))  ->  (in  e  S);  eqtii\alence-prcserving  if  f  is  injective 

4:23  (IN  [HAND  ME]  [PROJECT  HANO  (PLAYERS)]) 

--->  (IN  ME  (PLAYERS)) 

5:23  (IN  [CARD-OF  ME]  [PROJECT  CARO-OF  (PLAYERS)]) 

--->  (IN  ME  (PLAYERS)) 


RUI.E172  is  a  shortcut  for  the  sequence: 

(IN  (f  e)  (PROJECT  f  S)) 

---  [by  RULE14]  ---> 

(EXISTS  x  S  (*  (f  e]  [f  x])) 

---  [REDUCE  by  RULE 43 .  SIMPLIFY  by  RULE  1 78]  ---> 

(EXISTS  x  S  (=  e  x)) 

---  [RECOGNIZE  by  RULE162]  ---> 

(IN  e  S) 

RULE192:  ( =  [Q  x  S  Px]  [Q  y  S  Ry])  ->  ( =  Py  Ry) 

(=  [FORALL  PI  (INOICES-OF  CAROS-PLAYED 1 ) 

(  =  >  (IN  ME  (INOICES-OF  CARDS-PLAYED1 ) ) 

(AND  (IN  (CARDS-PLAYED1  ME) 

(CARDS- IN-SUIT -LED  CARDS -PLAYED1 ) ) 

(=>  (=  (SUIT-OF  (CARDS-PLAYED1  PI))  (SUIT-LED)) 
r NOT  (HIGHER  (CARDS-PLAYED1  PI) 

(CARDS-PLAYED1  ME))))))] 

[FORALL  PI  (INDICES-OF  CAROS-PLAYEOl ) 

Qi]> 

(=  [EXISTS  Cl  (CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO)] 

[EXISTS  XI  ( CARDS- IN-HAND  PO)  (IN  XI  SI)]) 

(*  [FORALL  15  (INOICES-OF  PROJECT  1 ) 

(NOT  (HIGHER  (PROJECT1  15)  CLIMAX1))] 

[FORALL  II  (INDICES-OF  PROJECT1) 

02]) 

RULE322:  (  =  >  [f  c1 ...  en]  [exists  x  S  [f  e1’ ...  en']]>  ->T  if  (and  [in  x  S]  [=  eL  c^] ...  [=  enen’]) 

2:30  (=>  [HAS  PI  C2]  [EXISTS  P4  (OPPONENTS  ME)  [HAS  P4  C7 ] ] ) 

- >  T 

since  (ANO  [IN  P4  (OPPONENTS  ME)]  [=  PI  P4]  [=  C2  C7]) 


RUI.E322  is  a  shortcut  for  the  sequence: 

(->  [f  «i  ...  e„]  [EXISTS  x  S  [f  9l'  ...  en*]]) 

—  [restructure  by  RULE220]  - > 

(EXISTS  x  S  (->  [f  et  ...  e  ]  [f  et'  ...  e  '])) 
—  [reduce  by  RULE43]  — > 

(EXISTS  x  S  (AND  [•  e  et']  ...  [-  en  en'])) 

—  [eliminate  quantifier]  — > 


(ANO  [in  x  S]  [»  ej' ]...[*  en 
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RULE379:  ( =  >  [forall  x  Sj  PJ  [forall  y  S2  Pyj)  ->  T  if  (subset  S,  S,) 

13:22  (  =  >  [FOR.  .A  INTERVAL1  ( INTERVALS-OF 

(PROJECT  NOTE  ( LB : UB  1  ( CANTUS -LENGTH  ))) ) 
(USABLE-*  A ERVAL!  INTERVAL1 ) ] 

[FORALL  INTERVAL1  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVA1  !  INTERVAL1 ) ] ) 

- >  T 

Since  ( SU8SET  [INTERVALS-OF  (PROJECT  NOTE  ( LB : UB  1  ( CANTUS -LENGTH ))) ] 
[INTERVALS-OF  PROJECT.]) 

13:67  (=>  [FORALL  XI  (PROJECT  NOTE  ( La : UB  t  (CANT  US- LENGTH )) ) 

(NOT  (HIGHER  XI  CLIMAX1))] 

[FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX  1 ) )  ] ) 

- >  T 

since  (SUBSET  [PROJECT  NOTE  ( LB : UB  1  ( CANTUS -LENGTi.) ) ]  PROJECTl) 


RULF.380-.  ( =  [forall  x  S1  Px]  [forall  v  S,  R  J)  ->  ( =  Ry  (or  Py  [in  y  (cliff  S,  SJ))) 

13:31  (=  [FORALL  14  (L8:UB  2  (0  PROJECTl)) 

(USABLE-INTERVAL! 

(INTERVAL  (PROJECTl  (-  14  1))  (PROJECTl  14)))] 
[FORALL  II  (INDICES-OF  PROJECTl)  Ql]) 

- >  (-  Ql  (OR  [USABLE-INTERVAL! 

(INTERVAL  (PROJECTl  (-  II  1))  (PROJECTl  II))] 
[IN  II  (DIFF  (INDICES-OF  PROJECTl) 

(L8:U8  2  (#  PROJECTl)))])) 

RLI.E388:  (subset  [set-of  x  S(  PJ  [set-of  y  S2  PJ)  ->  T  if  (subset  SL  SJ 

13:97  (SUBSET  [SET-OF  X3  PROJECTl  (=  X3  CLIMAX1)] 

[SET-OF  X4  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH) )  ) 
(=  X4  CLIMAX1 ) ]  ) 

- >  T 

since  (SUBSET  PROJECTl  [PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))]) 


5.3.5.  Recurrence  Equations 

Partial  matching  is  also  used  to  induce  the  definition  of  a  function  from  a  recurrence  equation.  A 
recurrence  equation  of  the  form  /:(c)  =  (g  ...  c  ...)  has  a  solution  h  =  (lambda(x)  (g  ...  x  ...)]. 
Similarly,  an  equation  e  =  Mg  ...  e  ...)  has  a  solution  h  =  [tambda(x)  (g  ...  x  ...))'*.  These  solutions  arc 
not  unique,  but  arc  natural  in  a  certain  intuitive  sense. 

Recurrence  equations  of  die  form  Me)  =  (g  ...  c  ...)  arc  solved  by  a  rule  used  to  reformulate  an 
expression  as  a  function  of  a  given  quantity  (§4): 

RULE315:  (reformulate  [g  ...  e  ...]  e)  ->  ([lambda  (x)  (g  ...  x  ...)]  e) 

The  construct  (reformulate  [g  ...  e  ...]  e)  can  be  paraphrased  as  '‘solve  Me)  =  (g  ...  e  ...)  for  h  and 
rewrite  (g  ...  e  ...)  as  /.(c)."  RULH315  is  used  in  DHRIV2  to  reformulate  the  success  criterion  for  a 
heuristic  search  as  a  predicate  on  a  choice  sequence  (§3.3.3): 
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(REFORMULATE  [DURING  (TRICK)  (TAKE-POINTS  ME)]  [CAROS- PLAYED] ) 


The  condition  that  e  occur  in  the  expression  to  be  reformulated  is  satisfied  by  analysis: 

2:18  —  [by  analysis] - > 

(REFORMULATE  [AND  (HAVE-POINTS  (CARDS-PLAYED) ) 

(*  (CARD-OF  ME) 

(HIGHEST -IN-SUIT -LED  (CARDS-PLAYED) )) ] 
[CARDS-PLAYED]) 


Then  RULF.315  is  applied  with  e  =  (CARDS-PLAYED).  x  =  CARDS-PLAYEOl  to  construct  the 

desired  function: 

2:19  ---  [by  RULE 3 13]  ---> 

([LAMBDA  (CARDS-PLAYEOl) 

(AND  (HAVE-POINTS  CARDS-PLAYEOl) 

(=  (CARD-OF  ME)  ( HIGHEST- IN-SUIT -LED  CARDS-PLAYED1) ) ) ] 
(CARDS-PLAYED)) 


RULF.315  is  also  used  in  DF.RIV13: 

(REFORMULATE  [LEGAL-CANTUS !  (PROJECT  MOTE  ( LB : UB  1  ( CANTUS -LENGTH ))) ] 
[PROJECT  NOTE  ( LB : UB  1  ( CANTUS- LENGTH ))] ) 

13:15  ---  [by  RULE315]  ---> 

([LAMBDA  ( PROJECT  1 )  (LEGAL-CANTUS!  PR0JECT1)] 

(PROJECT  MOTE  (LB:U3  1  ( CANTUS  -  LENGTH ))) ) 


Recurrence  equations  of  the  form  /’/(e)  =  (g  ...  e  ...)  are  solved  by 

RUI.F.211:  (=  (g  ...  e  ...)  (h  c-))  ->  ( =  h  (lambda  ( x)  (g  ...  x  ...)))  if  c  =  c\ 
where  e  and  e'  are  both  of  the  form  (f ...) 


Recurrence  equations  of  the  form  e  =  //( g  ...  c  ...)  are  solved  by 

RUI.F2212:  (=  e  [h  (g  ...  e' ...)])->(  =  h  [inverse  (lambda  (x)  (g  ...  \  ...))])  if  e  =  c’. 
where  c  and  e'  arc  both  of  the  form  (f ...) 


Since  such  recurrence  equations  can  have  non-unique  solutions,  tlicsc  rules  are  sound  rattier  than 
valid.  They  are  sufficiently  general  to  handle  equations  where  the  recurring  term  appears  in  two 
different  forms  whose  equality  can  be  verified  by  analysis.  This  feature  is  illustrated  in  DHRIV9  by 
the  solution  of  die  following  equation,  where  HI  is  the  unknown  function: 

(=  [EXISTS  Cl  ( CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO)] 

[HI  (DISJOINT  ( CARDS- IN-HANO  PO)  SI)]) 

The  condition  that  e  and  e'  share  the  form  (f ...)  is  satisfied  by  expanding  o'  =  (DISJOINT  ...): 
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9:3-4  ---  [ELA80RATE  by  RULE  124  ]  ---> 

(-  [EXISTS  Cl  (CAROS- IN-HAND  PO )  (IN-SUIT  Cl  SO)] 

[HI  (NOT  (EXISTS  XI  ( CARDS- IN-HAND  PO)  (IN  XI  SI)))]) 


ITic  condition  e  =  e’  is  verified  by  partial-matching  c  and  c'  and  solving  for  die  variable  SI: 


(=  [EXISTS  Cl  ( CAROS- IN-HANO  PO)  (IN-SUIT  Cl  SO)] 
[EXISTS  XI  ( CAROS- IN-HANO  PO)  (IN  XI  SI)]) 
9:6-12  ---  [REDUCE  by  RULE  192  ,  analysis]  ---> 


T 

SI  <-  ( CARDS- IN-SUI T  SO) 


TOO  generates  a  new  variable  name  EXISTS1  and  solves  for  HI: 

9:14  ---  [REDUCE  by  RULE215]  ---> 

(  =  HI  [INVERSE  (LAMBDA  { EXISTS  1 )  (NOT  EXISTS1))]) 

The  solution  is  simplified  by  rewriting  (lambda  (x)  (f  x))  as  f: 

9:15  ---  [SIMPLIFY  by  RULE215]  ---> 

(=  HI  [INVERSE  NOT]) 

The  solution  could  be  further  simplified  to  HI  =  NOT  based  on  die  knowledge  diat  the  function 
NOT  is  its  own  inverse.  This  was  unnecessary  for  the  purposes  of  die  derivation  but  could  be  done  by 
adding  the  relation  "INVERSE  of  NOT  is  NOT”  to  100‘s  semantic  network  (§1.3.2.21  and  adding  a 
general  rule  "( inverse  f)  ->  g.  where  g  is  the  inverse  of  f.” 


5.3.6.  Partial  Matching:  Summary 


Partial  matching  can  be  summarized  in  terms  of  why  to  do  it.  how  to  do  it,  and  what  it  produces: 

1.  Partial  matching  is  a  powerful  technique  for  eliminating  troublesome  concepts  (e.g.,  the 
undefined  relation  DURING)  from  an  expression.  Even  when  the  concepts  in  die  expression 
have  definitions  (e.g..  the  action  TAKE),  partial  matching  can  still  be  useful:  by  exploiting 
concept  properties  instead  of  expanding  definitions,  it  facilitates  high-level  analysis. 

2.  Partial  matching  typically  transforms  a  relation  between  similar  (Le.,  based  on  the  same 
function)  expressions  to  a  conjunction  of  equalities.  The  usual  partial  matching  scenario 
consists  of  the  following  steps: 

a.  Reformulate  an  expression  in  terms  of  die  relation. 

b.  Translate  its  arguments  in  terms  of  a  common  function. 

c.  Restructure  die  expression  into  die  right  form. 

d.  Match  the  corresponding  arguments. 

e.  Simplify  the  result  into  a  useful  form. 
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3.  The  resulting  expression  is  generally  a  sufficient  condition  on  the  original  predicate;  whether 
it’s  a  necessary  condition  as  well  may  depend  on  subtle  properties  of  the  task  domain  and  the 
way  it  is  modelled  by  the  knowledge  base.  Hvcn  when  partial  matching  is  not  a  logically  valid 
transformation,  treating  it  as  one  may  be  empirically  justified  by  the  performance  of  the 
resulting  operationalizations.  Moreover,  logical  soundness  su ffices  for  certain  problems,  such  as 
finding  a  natural  solution  to  a  recurrence  equation. 


5.4.  Variables,  Assumptions,  and  Finding  Examples 

In  roo's  transformational  organization,  most  of  the  problem-solving  state  is  encoded  in  the  current 
expression  (or  stack  of  expressions,  since  subgoaiing  is  permitted).  Communication  between 
different  branches  of  the  problem-solving  process  can  be  a  bit  awkward  within  this  organization.  1 
therefore  added  mechanisms  to  permit  global  cotnmunicaiion  via  variables  and  assumptions.  For 
instance,  an  assumption  made  in  the  course  of  solving  a  subproblem  is  stored  on  a  global  list  of 
assumptions,  from  which  it  can  be  retrieved  and  used  to  simplify  other  subproblems.  Similarly,  the 
binding  assigned  to  a  variable  in  the  course  of  solving  a  subproblem  can  be  used  to  simplify  other 
subproblcms  where  the  variable  occurs.  This  provides  a  natural  way  to  express  problems  that  don’t 
readily  fit  the  transformational  paradigm,  e.g.,  the  problem  of  assigning  values  to  the  arguments  of  a 
function  in  such  a  way  as  to  make  the  resulting  expression  satisfy  some  property. 

A  potential  refinement  would  be  a  mechanism  for  associating  variables  and  assumptions  with 
different  contexts,  as  in  partitioned  semantic  networks  [Hendrix  75]  and  truth  maintenance 
systems  [Doyle  81].  Such  a  mechanism  could  keep  track  of  alternative  assumptions  and  variable 
bindings  by  putting  them  in  different  contexts.  As  implemented,  FOO  has  no  mechanism  for 
abandoning  one  assumption  in  favor  of  another,  backtracking  from  a  wrong  guess  about  the  value  of 
a  variable,  or  investigating  multiple  possibilities  in  parallel  if  they  involve  conflicting  assumptions  or 
variable  assignments.  This  limitation  is  not  serious  in  FOO’s  user-guided  mode,  but  would  have  to  be 
rectified  in  a  more  autonomous  system  (§8.1.1). 

This  section  presents  rules  that  solve  for  variables,  plug  in  the  results,  make  assumptions,  use  them, 
and  find  elements  of  intcnsionally  defined  sets.  (§5.4.1)  describes  FOO's  mechanisms  tor  solving 
variables  and  plugging  in  their  values.  (§5.4.2)  proposes  a  way  to  solve  inequalities  by  assuming  the 
compared  expressions  can  be  expressed  in  terms  of  the  same  concept.  (§5.4.3)  presents  rules  for 
making  and  using  assumptions.  (§5.4.4)  discusses  how  to  find  an  example  clement  of  an  intcnsionally 
defined  set.  This  is  closely  related  to  solving  for  tie  value  of  a  variable:  example- finding  can  be 
represented  as  solving  for  x  in  an  equation  of  the  form  (in  x  S).  The  key  to  example- finding  is 
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knowing  where  to  look  for  plausible  candidates;  some  of  roo's  rules  try  the  assumption  list  -•  another 
connection  between  example-finding  and  global  communication.  Finally.  (§5.4.5)  classifies  FOO’s 
communication  rules  according  to  die  source  and  destination  of  the  information  they  propagate. 

5.4.1.  Solving  for  Variables 

Solving  an  equation  is  die  same  as  proving  a  proposition  except  that  besides  the  usual  proof 
operations,  the  variables  in  the  equations  can  be  assigned  values;  any  consistent  assignment  that 
makes  the  equation  a  true  proposition  constitutes  a  solution.  Equations  are  solved  in  FOO  with  the 
usual  apparatus  for  proving  propositions,  plus  tw-o  rules  diat  solve  for  variables,  and  a  rule  that  plugs 
in  the  value  of  a  solved  variable: 

RULE194:  (  =  v  e)  ->  T,  setting  v  to  e,  if  v  is  an  unbound  variable 
RULE271:  ( =  e  v)  ->  T,  setting  v  to  e,  if  v  is  an  unbound  variable 
RULE127:  v  ->  e  if  variable  v  has  been  set  to  e;  c  need  not  be  a  constant 

The  folowing  list  shows  some  of  the  variable  assignments  made  and  used  by  these  rules.  Notice 
diat  a  variable  may  be  assigned  not  only  a  constant,  but  an  expression,  another  variable,  or  an 
expression  containing  unbound  variables.  Thus  global  variables  can  be  used  to  propagate  partial 
information. 

6:51  CAR01  <-  OK  —  constant 

3:56  Pt  <-  (QSO)  —  expression 

3:53  C4  <-  C3  -variable 

2:34  Q 1  <-  (=>  (NOT  (AFTER  ME  PI)) 

(AND  [IN  (CARDS-PLAYED1  ME) 

(CAROS- IN-SUIT -LED  CARDS- PLAYED1 ) ] 

[=>  (=  ( SUIT -OF  (CARDS-PLAYED1  PI))  (SUIT-LED)) 

(NOT  (HIGHER  ( CAR0S-PLAYED1  PI) 

(CARDS-PLAYEOI  ME  )})])}  "  condition 

9:16  HI  <-  (INVERSE  NOT )  —  function-valued expression 

9:13  SI  <-  ( CAROS- 1 N-SUIT  SO)  --  expression  containing  independent  variable 

11:3  Cl  <-  (CARD-OF  PI)  --  expression  containing  quantifier  variable 

13:38  Q1  <-  (OR  [USABLE-INTERVAL!  (INTERVAL  (PR0JECT1  (-  II  1)) 

(PROJECT!  II))] 

[  *  II  1  ] ) )  -  quantified  condition 

13:75  Q2  <-  (NOT  (HIGHER  (PROJECT!  II)  CLIMAX  1) ) --  musical  constraint 
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Solving  ( =  v  e)  for  v  is  trivial.  It's  harder  to  solve  for  v  based  on  a  comparison  (R  v  e)  when  R  is 
not  the  equality  relation,  but  one  approach  for  doing  so  is  to 

Assume  compared  expressions  can  be  expressed  in  terms  of  the  same  function. 


This  idea  is  expressed  in  a  variant  of  RULE271  proposed  in  (§3. 5.5.5): 

RULE271a:  (R  [f  e1 ...  en]  e)  ->  (R  (f el ...  cn]  [f  ...  vj),  assuming  e  =  (f  v1 ...  vn) 

RULE271a  would  help  reduce  the  goal  (»<  [MELODIC- RANGE  PROJECTl]  (major  io))  of 

keeping  the  melodic  range  of  a  generated  tone  sequence  PR0JECT1  within  a  major  tenth  to  the 

problem  of  choosing  and  enforcing  a  priori  bounds  on  its  lowest  and  highest  notes.  The  first  step  in 

such  a  reduction  would  plug  in  the  definition  of MELOOIC-RANGE: 

(=<  [MELODIC-RANGE  PR0JECT1]  (MAJOR  10)) 

---  [ELABORATE  by  RULE124]  ---> 

(=<  [SIZE  (INTERVAL  (LOWEST  PR0JECT1)  (HIGHEST  PROJECT  1 ) ) 3 
(MAJOR  10)) 


Applying  RfLF.271a  with  R  =  »<,f=  SIZE.  Cj  =  (interval  ...),  e  =  (major  io),andVj 

=  intervali  would  suggest  assuming  (MAJOR  10)  to  be  the  SIZE  of  something,  since  it's 

compared  to  (SIZE  (INTERVAL  ...))  by  the  =<  relation: 

(=<  [SIZE  (INTERVAL  (lOWEST  PR0JECT1)  (HIGHEST  PROJECT  1 ) ) ] 

(MAJOR  10)) 

---  [assume  (MAJOR  10)  =  (SIZE  INTERVALI )  by  RULE271a]  ---> 

(=<  [SIZE  (INTERVAL  (LOWEST  PROJECT1)  (HIGHEST  PROJECT1))] 

[SIZE  INTERVALI]) 


The  assumption  that  (MAJOR  10)  is  the  SIZE  of  an  interval  allows  the  problem  to  be  reduced: 

(«<  [SIZE  (INTERVAL  (LOWEST  PR0JECT1)  (HIGHEST  PROJECT  1 ) ) ] 

[SIZE  INTERVALI]) 

---  [REDUCE  by  RULE234]  ---> 

(SUBSET  [INTERVAL  (LOWEST  PROJECTl)  (HIGHEST  PR0JECT1)] 

INTERVALI) 


Here  INTERVALI  denotes  the  “something"  v  whose  SIZE  is  (MAJOR  10).  The  fact  that 
INTERVALI  is  compared  to  (INTERVAL  (LOWEST  PROJECTl)  (HIGHEST  PROJECTl))  by  the 
SUBSET  relation  suggests  that  INTERVALI  is  the  interval  between  two  things,  call  them  LOWEST  l  and 
HIGHEST1.  This  inference  is  ghen  by  RUI.E271a  with  R  =  SUBSET,  f  =  INTERVAL,  Cj  = 
(LOWEST  PROJECTl),  e,  =  (HIGHEST  PROJECTl),  e  =  INTERVALI,  v  =  L0WEST1.  v2  = 
HIGHEST  1: 
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(SUBSET  [INTERVAL  (LOWEST  PROJECT  1 )  (HIGHEST  PROJECT1)] 

INTERVAL  1 ) 

- [assume  INTERVAL1  =  (INTERVAL  LOWEST1  HIGHEST  1 )  by  RULE271a]  — -> 

(SUBSET  [INTERVAL  (LOWEST  PROJECT1)  (HIGHEST  PROJECT1)] 

[INTERVAL  LOWES T 1  HIGHEST  1  ] ) 


Explicitly  designating  LOWEST1  and  HIGHEST  1  as  notes  forming  an  INTERVAL  whose  SIZE  is 

(MAJOR  10)  makes  it  possible  to  satisfy  the  original  constraint  on  die  MELOOIC-RANGE  of  the 

generated  sequence  PROJECT  1  by  making  them  a  priori  bounds  on  the  lowest  and  highest  notes: 

(SUBSET  [INTERVAL  (LOWEST  PROJECT1)  (HIGHEST  PROJECT1)] 

[INTERVAL  LOWEST  1  HIGHEST  1]) 

—  [by  analysis  based  on  knowledge  about  intervals]  — > 

(AND  [NOT  (LOWER  (LOWEST  PROJECTt)  LOWEST1)] 

[NOT  (HIGHER  (HIGHEST  PROJECT  1 )  HIGHEST  1 ) ]) 

—  [by  analysis  based  on  transitivity  of  LOWER.  HIGHER]  — > 

(FORALL  NOTE  1  PROJECTl 

(AND  [NOT  (LOWER  NOTE  1  LOWEST1)] 

[NOT  (HIGHER  NOTE  1  HIGHEST  1 ) ] ) ) 


Thus  Rll.E271a  restricts  the  problem  (R  [f  ...[  c)  by  adding  the  plausible  assumption  that  the 
quantity  c  to  which  (f ...)  is  compared  can  also  be  expressed  in  the  form  (f ...).  The  revised  problem 
(R  |f  ...]  [f  ...])  can  dien  be  reduced  by  various  analysis  methods  based  on  knowledge  about 
homomorphisms.  transitivity,  interval  arithmetic,  etc. 


5.4.3.  Propagating  Assumptions 

100  maintains  a  global  (with  respect  to  a  derivation)  list  of  assumptions  of  the  form 
Assume  that  expression  c  has  value  v. 

The  value  need  not  be  a  constant.  To  make  an  assumption,  TOO  adds  e  =  v  to  the  list.  To  assume 
an  arbitrary  proposition  P  is  true  (or  false),  TOO  adds  e  =  T  (or  e  =  nil)  to  the  list.  The  assumption 
can  be  applied  by  substituting  v  for  e  later  in  the  problem.  The  rules  used  to  make  and  retrieve 
explicit  assumptions  appear  below,  each  one  followed  by  examples  of  its  use. 

RULE15:  (partition  St  ...  S^)  ->  (union  SL ...  Sn)  assuming  (disjoint  ...  Sn) 

(PARTITION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  ($ET  DECK  POT  HOLE)) 

RULF.15  unpacks  the  embedded  assertion  (disjoint  Sj ...  S  )  and  makes  it  an  explicit  assumption. 


RULE157:  (  =  >  PQ)  •>  Q  assuming  P 
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(*>  [IN  QS  (CAROS-PLAYED)] 

[HIGHER  OS  (CARD-OF  ME)]) 

This  assumes  that  QS  will  be  played,  so  as  to  plan  accordingly  (§2.9.2.2). 

RULE221:  P  >  T  assuming  P.  where  P  is  a  proposition  to  be  verified 

(SUBSET  PROJECT  1  (PROJECT  NOTE  (L3:UB  1  (CANTUS-LENGTH) ) ) ) 

This  proposition  is  an  instance  of  a  general  fact  about  heuristic  search  (§3.1),  namely  that  every 
partial  path  is  a  prefix  of  the  choice  sequence.  POO  has  no  mechanism  for  indexing  such  facts  under 
the  methods  they  describe.  Such  an  indexing  mechanism  might  help  a  complete  operationalization 
system  retrieve  relevant  facts  quickly  instead  of  examining  all  Riles. 

RULE302:  (and  ...  P  ...  [...  P  ...] ...)  ->  (and  ...  P  ...  [...  T  ...] ...) 

5:42  (IN  QS  ( CAROS- PLAYEO) )  --->  T 

14:56  (HIGHER  (HIGHEST  (CHANGE  CANTUS-1))  (HIGHEST  CANTUS-1))  --->  T 
14:74  (HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1))  --->  T 

RULF.3Q2  uses  one  branch  of  a  conjunction  to  simplify  another  by  treating  it  as  a  premise.  As 
implemented,  RULF.302  searches  the  expression  in  which  P  occurs,  and  any  higher-level  goals  on  the 
stack,  to  sec  if  P  occurs  anywhere  else;  the  user  must  decide  whether  it  occurs  as  a  premise. 

RULE342:  ( =  c  e)  ->  T  assuming  e  =  c.  where  c  is  a  constant 
3:26  (=  S  (SUIT-LED))  --->  T 

RU1.E346:  e  ->  v  if  e  -  v  was  assumed  earlier 
3:62  (SUIT-LED)  --->  S 
3:84  (LEADING  (QSO))  --->  NIL 

4:17  (DISJOINT  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 
--->  T 

6:55  (CARD-OF  (LEAOER ) )  --->  DK 
8:12  (IN  Cl  (CARDS))  --->  T 

13:47  (SUBSET  PROJECTl  (PROJECT  NOTE  (L8:U8  1  ( CANTUS -LENGTH ) ) ) )  --->  T 

With  two  exceptions,  these  assumptions  were  generated  by  rules  described  in  this  section.  To 
simulate  the  retrieval  of  situation-specific  information  from  a  state  model.  1  hand-coded  die 
assumption  (CARD-OF  (LEADER))  =  OK  for  the  dynamic  operationalization  (§S.1.6)  variant  of 
DF.RIV6.  To  simulate  typed  variables,  I  added  die  assumption  (IN  Cl  (CARDS) )  in  DF.R1Y3. 
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RULE349:  ( =  >  P  Q)  ->  T  assuming  P  =  nil 
3:80  (=>  [LEADING  (QSO)] 

[OR  (CAN-LEAD-HEARTS  (QSO))  (NEQ  (SUIT-OF  C3)  H))]) 

--->  T 

This  mles  out  the  case  where  player  (QSO)  leads,  so  as  to  pursue  the  case  where  ( QSO)  follows. 

RULE351:  (achieve  P) ->  (achieve  (and  [=  e,  v  J  ...  [=  en  vn)))> 

where  et  =  v  ...  cn  =  v  are  the  assumptions  used  in  reducing  the  original  goal  to  P 

3:88  (ACHIEVE  (PLAY-SPADE  (QSO))) 

--->  (ACHIEVE  (AND  [=  (LEADING  (QSO))  NIL]  [  =  (SUIT-LED)  S])) 


RUI.E351  is  only  valid  when  the  assumptions  arc  in  fact  strong  enough  to  imply  P.  In  the  example 
shown,  tins  implication  follows  from  the  rules  of  the  game. 


5.4.4.  Finding  Examples 


A  problem  similar  to  solving  for  the  value  of  a  variable  is  that  of  finding  an  clement  of  an 
intcnsionally  described  set.  This  is  a  difficult  problem  in  general,  but  t  oo  has  some  special-case  rules 
that  work  in  simple  cases.  These  rules  are  listed  below  with  examples  of  their  use. 

RULES4:  (...  [in  c  S[ ...  [find-elt  S'[ ...)  ->  (...  (in  c  S(...  c  ...)  if  (in  c  S’),  where  c  is  a  constant 


RULE84  proposes  c  as  a  possible  clement  of  a  set  S’  if  the  current  expression  says  that  c  is  in  S. 
The  implementation  requires  that  (in  c  S)  occur  as  a  premise.  For  example,  in  DF.R1V5.  the 
condition  (IN  qs  ( CARDS-  played  ) )  occurs  as  such  a  premise  in  the  goal 
(=>  [IN  QS  ( CAROS- PLAYED ) ] 

(HIGHER  [FINO-ELT  ( CARDS- IN-SU IT -LED  ( CARDS- PLAYED )) ] 

(CARO-OF  ME))) 


This  suggests  the  guess  (in  c  S’),  verified  by  subsequent  analysis: 

(IN  QS  (CAROS- IN- SUIT-LED  ( CARDS- PLAYED) ) ) 
5:40-41  —  [by  analysis]  — > 

(AND  [IN  QS  (CARDS-PLAYED)]  [IN-SUIT-LED  QS]) 

(IN  QS  (CARDS-PLAYED)) 

5:42  —  [by  premise]  — > 

T 


5:43-48 


(AND  T  [IN-SUIT-LED  QS]) 
—  [by  analysis]  — > 

T 
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The  constant  QS  is  used  as  the  desired  member  of  S.  reducing  the  goal  to  (...  [in  c  S] ...  c  ...): 

(=>  [IN  OS  (CARDS-PLAYEO )  ] 

(HIGHER  QS  (CARD-OF  ME))) 


Note  the  use  of  die  premise  in  verifying  the  guess. 

RULE109:  (not  (and  ...  [forall  x  S  PJ  ...))->(  =  >  [and  ...J  [not  p(rm(1.eU  S|l) 
To  negate  a  universally  quantified  predicate,  find  a  counter-  example. 


In  DERIV5  and  DERIY6,  RL'LF.109  suggests  finding  a  card  played  in  die  suit  led  that's  higher 

dian (CARD-OF  ME): 

(NOT  (AND  [IN  QS  (CARDS-PLAYEO)] 

[FORALL  XI  (CARDS- IH-SU IT -LED  (CAROS-PLAYED) ) 

(NOT  (HIGHER  XI  (CARD-OF  ME)))])) 

5:35  ---  [by  RULE  109]  — > 

(=>  [AND  (IN  QS  (CAROS-PLAYED))] 

[NOT  (NOT  (HIGHER  [FINO-ELT  t CARDS- IN-SU IT -LED  ( CARDS- PLAYED )) ] 
(CARO-OF  ME)))]) 

5:37-33  ---  [SIMPLIFY  by  RULE173 ,  RULE88]  ---> 

(=>  [IN  QS  (CARDS-PLAYED)] 

[HIGHER  [FINO-ELT  (CAROS- IN-SUIT-LED  (CARDS-PLAYED))] 

(CARD-OF  ME)]) 

(NOT  (AMD  [IN-SUIT-LEO  (CARD-OF  ME)] 

[FORALL  XI  (CARDS-IN-SUIT-LED  (CARDS-PLAYED)) 

(HOT  (HIGHER  XI  (CARD-OF  ME)))] 

[TRICK-HAS-POINTS])) 

6:40  ---  [by  RULE109]  ---> 

(=>  [AND  (IN-SUIT-LEO  (CARO-OF  ME))  (TRICK-HAS-POINTS)] 

[NOT  (NOT  (HIGHER  [FINO-ELT  (CARDS-IN-SUIT-LED  ( CAROS- PLAYEO )) ] 
(CARO-OF  ME)))]) 

6:41  ---  [SIMPLIFY  by  RULE88]  ---> 

(->  [AND  (IN-SUIT-LED  (CARD-OF  ME))  (TRICK-HAS-POINTS)] 

[HIGHER  [FINO-ELT  (CARD- IN-SUIT-LED  (CARDS-PLAYEO))] 

(CARO-OF  ME)]) 

RULE142:  (P  ...  (find-elt  S] ...)  ->  (and  [in  x  S]  Px),  where  x  is  a  new  variable 


In  DF.R1Y6,  RUI.F.142  reformulates  a  problem  of  example-finding  as  solving  an  equation  for 

CARD  l: 

(HIGHER  [FINO-ELT  ( CAROS - IN-SU I T -LED  (CARDS-PLAYED))] 

(CARO-OF  ME)) 

6:44  —  [in  0ERIV6  situation-specific  variant]  - > 

(ANO  [IN  CARD  1  ( CARDS - IN-SU I T -LEO  (CARDS-PLAYED))] 

[HIGHER  CARD1  (CARO-OF  ME)]) 


222 


§5.  Analysis  Methods 


6:45-46  —  [by  analysis]  - > 

(AND  [IN- SUIT-LED  CARD1] 

[IN  CARD  1  (PROJECT  CARO-OE  (PLAYERS))] 

[HIGHER  CARO  1  (CARO-OF  ME)]) 

6:47-48  ---  [by  RULE364 ,  assumption  (CARO-OF  (LEADER))  =  OK]  ---> 
CARD  1  <-  DK 

RULE-347:  (exists  x  S  P  )  ->  T  if  P  where  c  is  a  constant  occurring  in  Px 
To  satisfy  an  existentially  quantified  predicate,  find  a  positive  example. 


In  the  example  hetow.  RULE347  suggests  trying  c  =  QS: 

3:69  (EXISTS  C5  (CAROS)  (AND  [HAS  (OWNER-OF  QS)  C5]  [IN-SUIT  C5  S])) 

--->  T 

since  (AND  [HAS  (OWNER-OF  QS)  QS]  [IN-SUIT  QS  S]) 


RL'LF.364:  (in  y  (project  f  S3)  ->  T,  setting  y  to  v,  if  (in  e  S), 
where  y  is  an  unbound  variable  and  (f  e)  =  v  was  assumed  earlier 


RUI-F.364  finds  an  element  of  die  set  (project  fS)  by  solving  the  equation  (in  y  (project  f  S))  for 

y  ( §5.4  -4'*.  as  in  tlie  dy  namic  operationalization  (§8.1.6)  variant  of  DF.RIV6: 

6:47  (IN  CARD1  (PROJECT  CARD-OF  (PLAYERS))) 

--->  CARD  1  <-  DK 

since  (CARD-OF  (LEADER))  =  DK 

and  (IN  (LEADER)  (PLAYERS)) 


5.4.5.  Information  Propagation:  Summary 

1'he  rules  described  in  this  section  solve  for  variables,  exploit  assumptions,  and  find  examples  by 
propagating  information  among  assumptions,  problems,  and  variable  bindings. 

1.  Rules  for  solving  variables  (§5.4.1)  propagate  information: 

a.  from  an  equality  in  a  problem  to  a  global  variable  binding  (RULF.194,  RUFF271) 

b.  from  a  global  variable  binding  to  a  value  substitution  in  a  problem  (RUI.E127) 

2.  A  proposed  rule  for  solving  inequalities  (§5.4.21  propagates  information: 

a.  from  a  comparison  in  a  problem  to  a  restriction  on  the  value  of  a  variable  (RULF.271a) 

3.  Rules  for  using  assumptions  (§5.4.3)  propagate  information: 

a.  from  an  embedded  assertion  to  a  global  assumption  (RULF.15) 

b.  from  a  problem  clause  to  a  global  assumption  (RLI.F.157,  RULF221.  RULF342, 
RLLE349) 
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c.  from  a  problem  clause  to  a  value  substitution  in  a  problem  (RUL.F3Q2) 

d.  from  a  global  assumption  to  a  value  substitution  in  a  problem  (RUI.F346) 

e.  from  a  list  of  global  assumptions  to  the  problem  of  achieving  them  (RULF.351) 

4.  Rules  for  finding  examples  (§5.4.4)  propagate  information: 

a.  from  a  problem  clause  to  the  subproblem  of  finding  an  example  (RUI.F109.  RUI.H142) 

b.  from  a  problem  clause  to  a  suggested  example  (RITF84.  RULF347) 

c.  from  a  global  assumption  to  a  suggested  example  ( R I  I  F.364) 

These  rules  go  outside  of  the  expression-transformation  paradigm  to  communicate  between 
different  branches  of  the  problem-solving  process. 

5.5.  Recursive  Definitions 

When  it's  infeasible  to  provide  a  single  complete  definition  for  a  concept,  it  may  still  be  possible  to 
giv  e  a  set  of  special-case  rules  that  provide  a  partial  definition.  For  example,  consider  the  function 
CHOICE-SEQ-OF  whose  value  is  che  sequence  of choice  events  that  occur  as  part  of  a  given  event.  It  is 
not  immediately  clear  how  to  encode  in  roo's  representation  a  general  definition  of  the  form 

CHOICE-SEQ-OF  =  ( LAMBDA  (EVENT)  <...>) 

Such  a  definition  would  tell  how  to  extract  the  choice  event  sequence  of  an  arbitrary  event 
description,  but  filling  in  the  body  would  require  a  way  to  refer  to  tire  sub-events  of  EVENT  and  a 
predicate  that  tests  whether  a  given  event  is  a  choice  event.  It  is  easier  to  formulate  special-case  rules 
that  extract  the  choice  event  sequence  from  ev  ent  descriptions  of  particular  forms,  o.g..  explicit  choice 
events: 

RUI.E309:  (ehoicc-seq-of  (choose  x  S  F.x))  ->  (list  (choose  x  S  F.x)> 

The  choice  event  sequence  of  a  choice  event  is  the  list  consisting  of  that  event. 

Such  a  special-case  rule  may  be  recursive.  /.<?.,  its  right-hand  side  may  refer  to  the  concept  in 
question: 

RULF307:  (ehoice-scq-of  (each  x  S  F.x))  ->  (apply  append  (each  x  S  (ehoice-seq-of  E  ))) 

.4  scenario 's  choice  event  sequence  is  the  concatenation  of  as  components'  choice  sequences. 

This  section  shows  how  such  rules  are  used  in  roc  to  (partially)  define  three  general  concepts: 
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1.  the  functional  dependence  of  one  quantity  on  another  (§5,5.1). 

2.  the  choice  event  sequence  of  a  given  event  (§5.5.2). 

3.  the  domain  of  a  function  (§5.5.3). 


(§5.5.4)  lists  FOO’s  rules  about  these  concepts,  distinguishing  boundary  conditions  from  recursive 
rules. 


5.5.1.  Functional  Dependence 


(§2.S)  presented  a  calculus  of  four  dements  {0,  t.  4,  ?}  for  describing  how  one  quantity  depends 
on  another.  The  rules  below,  taken  together,  provide  a  partial  definition  of  the  DEPENDENCE 
function.  Examples  from  DERIV9  follow  each  rule. 

RUI.F203:  (dependence  [f  e( ...  ej  v)  -> 

(D+  ...  [D*  (dependence  (f  x,  ...  xn)  x()  (dependence  e|  v)j ...), 

where  (D-f  ...)  includes  a  term  [D*  ...]  for  each  e(  in  which  v  occurs  (chain  rule) 

(DEPENDENCE  [PR-OISJOINT-FORMULA  ( 0CARDS- IN-HAND  P0) 

(#CARDS -OUT-IN-SUIT  SO) 

( 0CARDS -OUT ) ] 

SO) 

9:45  ---  [by  RULE 203]  -  —  > 

(D+  [0*  (DEPENDENCE  ( #C ARDS -OUT- IN-SUIT  SO)  SO) 

(DEPENDENCE  ( PR-D IS00INT - FORMULA  #H  ft S  ft U)  #S)]) 

RULE204:  (dependence  c  v)  ->  nil  if  the  atom  v  doesn't  occur  in  e 

(DEPENDENCE  (#CH00SE  #U  #H)  ttS) 

9:51  ---  [EVAL  by  RULE204]  ---> 

NIL 

(DEPENDENCE  #U  #S) 

9:56  ---  [EVAL  by  RULE204  ]  ---> 

NIL 

RUI.E205:  (dependence  [f  Cj  e,l  v)  ->  (l)  +  (dependence  et  v]  (l>  (dependence  e,  v)]), 
where  tlx  y)  is  an  increasing  function  of  x  and  a  decreasing  function  of  y 

(DEPENDENCE  [/  (ft CHOOSE  (-  #U  #S )  ft  H)  (^CHOOSE  #U  #H)]  #S) 

9:50  ---  [by  RULE205 ]  — > 

(0+  [DEPENDENCE  (0CHOOSE  (-  #U  ft S)  #H)  #S] 

[0-  (DEPENDENCE  (#CH00SE  #U  #H)  ft S)]) 

(DEPENDENCE  (-  ftV  ftS)  #S) 

9:55  ---  [by  RULE2Q5]  ---> 

(0+  [DEPENDENCE  #U  #S]  [D-  (DEPENDENCE  #S  #S)]) 

RULF.207:  (dependence  (f  Cj  ...  en]  v)  ->  (dependence  gj  v)  if  v  doesn't  occur  in  c, ...  en. 
where  fisan  increasing  function  of  its  first  argument 
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(DEPENDENCE  [^CHOOSE  (-  #U  #S)  # H]  tfS) 
9:54  ---  [REDUCE  by  RULE207]  ---> 
(DEPENDENCE  (-  #U  #S)  #S) 

RULH208:  (dependence  e  c)  ->  increasing 

(DEPENDENCE  US  #S) 

9:57  [EVAL  by  RULE208]  ---> 
INCREASING 


5.5.2.  Choice  Sequence  Extraction 


Rules  for  extracting  the  choice  event  sequence  of  an  event  arc  used  in  DERIV2  and  DERIV'D. 

RULE307:  (choice-seq-of  [each  x  S  EJ)  ->  (apply  append  [each  x  S  (choicc-seq-of  E  )]) 

2:10  (CHOICE-SEQ-OF  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)]) 

--->  (APPLY  APPEND  [EACH  PI  (PLAYERS)  (CHOICE-SEQ-OF  (PLAY-CARD  PI))]) 

13:4  (CHOICE-SEQ-OF  [EACH  II  ( LB : UB  1  (CANT US -LENGTH)) 

(CHOOSE-NOTE  II)]) 

--->  (APPLY  APPEND  [EACH  II  (L8:UB  1  ( CANTUS-LENGTH) ) 

(CHOICE-SEQ-OF  (CHOOSE-NOTE  II))]) 


RUI.E308:  (choice-seq-of  S)  ->  nil  if  S  contains  no  choice  events 

2:7  (CHOICE-SEQ-OF  (TAKE-TRICK  (TRICK-WINNER)))  --->  NIL 


RULF309:  (choicc-seq-of  (choose  x  S  F.^))  ->  (list  (choose  x  S  Hx)) 

2:12  (CHOICE-SEQ-OF  [CHOOSE  (CARD-OF  PI)  (LEGALCARDS  PI) 

(PLAY  PI  (CARD-OF  PI))]) 

--->  (LIST  [CHOOSE  (CARO-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  (CARD-OF  PI))]) 

13:5  (CHOICE-SEQ-OF  [CHOOSE  (NOTE  II)  (TONES)  (NOTE  II)]) 

--->  (LIST  [CHOOSE  (NOTE  II)  (TONES)  (NOTE  II)]) 


roo  knows  that  CHOICE-SEQ-OF  is  a  homomorphism  from  events  to  choice  sequences  with  respect 
to  the  "addition''  operators  SCENARIO  and  append,  i.e..  that  the  homomorphism  condition  flx  +  y) 
=  f(x)  +’  fly),  or  in  LISP  syntax  (f  ( +  xy))=  ( +  ’  (f  x)  (f  y)).  is  satisfied  for  f  =  CHOICE-SEQ-OF, 
+  =  SCENARIO,  +  '  =  APPEND.  This  fact  is  encoded  as  the  semantic  relations 

CHOICE-SEQ-OF  is-a  HOMOMORPHISM  and  ADD  of  SCENARIO  is  APPEND  (§  1.3.2).  ft  justifies  the 
reduction 

(CHOICE-SEQ-OF  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))]) 

2:6  ---  [REDUCE  by  RULE234]  ---> 

(APPEND  [CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))] 

[CHOICE-SEQ-OF  (TAKE-TRICK  (TRICK-WINNER))]) 
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This  reduction  is  performed  by 

RULF.234:  (f ...  [g  Cj ...  ej  ...)  ->  (g'  [f ...  c]  ...j ...  [f ...  en  ...]), 

where  tire  function  (lambda  (x)  (f ...  x  ...))  is  a  homomorphism  with  respect  to  g  and  g’ 

Thus  knowledge  about  a  function  like  CHOICE-SEQ-OF  is  encoded  not  only  in  rules  that  mention  it 
by  name,  but  also  as  facts  exploited  by  rules  about  more  general  concepts  like  HOMOMORPHISM.  Thus 
any  rule  that  applies  to  a  function  can  be  considered  part  of  its  definition. 

5.5.3.  Domain  of  a  Function 

Rules  for  determining  die  domain  of  a  variable  in  an  expression  arc  used  in  DHR1V9.  The 
notation  (domain  x  e)  means  “the  domain  of  x  as  it  is  used  in  e";  die  notation  (domain  f)  means  “the 
domain  of  the  (unction  f.”  The  following  rules,  shown  w  ith  examples  of  their  use.  simulate  a  kind  of 
type  inheritance. 

RULE- 195:  (domain  x  [f ...  e  ...])  ->  (domain  x  c)  if  x  occurs  in  e 

9:9  (DOMAIN  Cl  [*  (SUIT-OF  Cl)  SO]) 

-->  (DOMAIN  Cl  (SUIT-OF  Cl)) 

RULE196:  (domain  x(fx))  ->  (domain  0 

9:10  (DOMAIN  Cl  (SUIT-OF  Cl)) 

--->  (DOMAIN  SUIT-OF) 

RUI.FT97:  (domain  suit-of)  ->  (cards)  -  Hearts- specific  fact  (§1.3.3) 

9:11  (DOMAIN  SUIT-OF) 

--->  (CARDS) 

5.5.4.  Recursive  Definitions:  Summary 

In  FOO,  sets  of  special-case  ailes  (partially)  define  concepts  that  arc  difficult  to  encode  as  lambda 
expressions.  Each  rule  set  includes  boundary  condition  rules: 

RULE204:  (dependence  c  v)  ->  nil  if  the  atom  v  doesn't  occur  in  e 

RULF.208:  (dependence  e  c)  ->  increasing 

RULE308:  (choice-scq-of  S)  ->  nil  if  S  contains  no  choice  events 

RULE309:  (choice-seq-of  (choose  x  S  F.x))  ->  (list  (choose  x  S  Ex)) 

RUI.F.197:  (domain  suit-of)  •>  (cards) 
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Each  set  also  contains  recursive  rules  whose  right-hand  side  mentions  the  concept: 

RULE203:  (dependence  [f  e( ...  en]  v)  -> 

(D+  ...  [D*  (dependence (fxj ...  xn)  xd (dependence  e;  v)] ...), 

where  the  sum  (D+  ...)  includes  a  term  [D*  (...)  (...))  for  each  e;  in  which  v  occurs  (chain  rule) 
RULE307:  (choice-scq-of  [each  x  S  F.J)  ->  (apply  append  [each  x  S  (choicc-seq-of  H^))) 
RULE195:  (domain  x  [f ...  e  ...])  ->  (domain  x  e)  if  x  occurs  in  e 

Knowledge  about  a  concept  can  be  encoded  not  only  in  rules  that  mention  it  specifically,  but  also 
as  tacts  like  "CuoiCE-SEQ-OF  is  a  homomorphism"  exploited  by  more  general  ailes  like 

RUI.E284:  (f ...  [g  et ...  e^J ...)  ->  (g'  [f ...  e( ...[ ...  [f ...  cn ...])  if  f  is  a  homomorphism, 
where  g,  g'  correspond  to  +  ,  +  ‘  in  the  homomorphism  condition  fix  +  y)  =  fix)  +’  (Ty) 

5.6.  Intersection  Search 

A  powerful  technique  for  solv  ing  a  problem  is  to 

Reduce  ilie problem  lo  finding  a  path  between  two  nodes  in  a  prccomputable  network. 

Such  a  path,  if  it  exists,  can  be  found  in  bounded  time  by  a  general  intersection  search  algorithm. 
Even  if  the  original  problem  can't  be  reduced  to  an  intersection  search,  the  technique  is  still  useful  if 
the  existence  of  such  a  path  is  a  necessary  condition  for  die  existence  of  a  solution.  In  this  case, 
searching  for  a  path  and  failing  to  find  one  is  a  logically  valid  (and  typically  cheap)  way  to  identify 
insoluble  problems.  Intersection  search  may  be  impractical  if  the  network  is  expensive  to  generate, 
but  this  problem  was  not  encountered  in  the  examples  implemented.  The  network  nodes  for  these 
examples  correspond  to  concepts  in  the  knowledge  base,  and  the  connections  between  them  arc 
determined  by  the  concept  definitions  in  a  simple  way  that  is  easy  to  compute. 

This  section  illustrates  the  use  of  intersection  search  to  decide  whether  an  event  can  occur  during  a 
scenario  (§5.6.1),  to  discriminate  between  deterministic  and  non-detcnninistic  scenarios  (§5.6.2),  and 
to  find  a  common  superset  of  two  sets  (§5.6.3). 
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5.6.1.  Identifying  Impossible  Events 

A  recurring  problem  in  operationalisation  is  to  determine  whether  one  kind  of  event  can  occur 
during  another,  as  illustrated  by  questions  that  arise  in  operationalising  Hearts  advice: 

Can  a  player  take  a  card  during  the  part  of  a  trick  in  which  cards  are  played? 

Can  a  player  take  points  during  this  part  of  a  trick? 

Can  a  card  get  into  a  player's  hand  while  the  round  is  in  progress? 

Does  a  player  who's  void  in  a  suit  remain  void  for  the  rest  of  the  round? 

These  questions  can  be  answered  quickly  by  intersection  search  through  a  network  with  nodes 
representing  types  of  events,  and  arcs  representing  "part-of  and  “kind-of  relationships,  using 

RULES?:  (during  s  e)  •>  nil  if  no  sub-event  of  s  can  be  the  same  kind  of  event  as  e 

For  dais  method  to  work,  both  s  and  c  must  be  expressed  in  terms  of  event  types  encoded  in  the 
network.  As  implemented.  I'OO  extracts  "part-of’  and  "kind-of  relationships  between  event  types 
by  examining  their  definitions,  rather  than  encoding  them  as  arcs  in  a  separate  data  structure, 
although  tins  would  be  easy  enough  to  do.  Thus  die  search  takes  place  in  a  virtual  network  rather 
than  a  physical  one.  t  oo  uses  recursive  procedures  to  enumerate  the  sub-events  of  s  and  the 
abstractions  of  e:  if  these  two  sets  are  disjoint,  die  rule  condition  is  satisfied. 

The  sub-events  of  a  scenario  arc  defined  recursively  as  follows: 

51.  f  is  a  sub-event  of  (f  Cj ...  cn)  unless  f  is  a  low-level  event  like  MOVE  or  BECOME. 

52.  If  f  is  defined  is  (lambda  (...)  (g  ...)),  the  sub-events  of  f  include  those  of  (g  ...). 

53.  The  sub-events  of  (scenario  c.  ...  e  )  consist  of  diose  of  each  of  c,  ...  c  . 

54.  The  sub-events  of  (0  x  S  F.x)  arc  those  of  1-^  if  Q  is  FOR-SOME,  EACH,  or  CHOOSE. 

55.  The  sub-events  of  (while  P  e)  consist  of  diose  of  e. 

The  ubsiraetioris  of  an  event  arc  defined  recursively  as  follows: 

Al.  fis  an  abstraction  of  ( f  ...  cn)  unless  f  is  SCENARIO  or  a  low-lcvcl  event. 

A2.  If  fis  defined  as  (lambda  (...)  (g  ...)),  the  abstractions  of  f  include  those  of  (g  ...). 

A3.  The  abstractions  of  (and  e( ...  e  )  consist  of  those  of  each  of  ...  e^. 

A4.  The  abstractions  of  (while  P  e)  consist  of  those  of  e. 

AS.  T  he  abstractions  of  (0  x  S  F.  )  consist  of  those  of  Ex  unless  Q  is  EACH. 
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The  rest  of  this  section  shows  in  detail  how  RULE57  is  used  to  derive  four  facts: 

1.  The  Queen  of  spades  can't  be  taken  while  cards  are  being  played.  (§5.6.1. 1) 

2.  Points  can't  be  taken  while  cards  are  being  played.  (§5.6.1. 2) 

3.  Cards  can’t  become  “out"  while  the  round  is  in  progress.  (§5. 6. 1.3) 

4.  Voids  can't  be  undone  while  the  round  is  in  progress.  (§5.6. 1.4) 

The  variations  exhibited  in  the  examples  demonstrate  RULF57’s  generality. 


5.6.1. 1  Queen  Can't  be  Taken  While  Cards  are  Played 


RULE57  can  be  illustrated  by  showing  how  it  is  used  in  DF.RIV5  to  make  the  reduction 
(DURING  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)]  [TAKE  ME  QS])  ->  NIL 


First  roo  finds  the  sub-events  of  (EACH  Pi  (PLAYERS)  (PLAY-CARD  Pi)).  By  S4,  these 
include 

PLAY-CARD  = 

(LAMBDA  (P) 

(CHOOSE  (CARD-OF  P)  (LEGALCARDS  P) 

(PLAY  P  (CARD-OF  P ) ) ) 


By  S2,  S4,  and  SI,  the  sub-eveiiLs  of  PLAY -CARD  include 
PLAY  = 

(LAMBDA  (PC) 

(MOVE  C  (HAND  P)  POT)) 

The  event  play  has  no-subevents  by  the  definition  above.  If  MOVE  were  considered  a  sub-event,  it 
would  be  a  sub-event  of  every  action  in  Hearts.  Any  two  actions  would  have  move  as  a  common  sub¬ 
event.  so  RU1.E57  would  never  apply.  MOVE  is  “low-level"  rather  than  "primitive"  since  it  actually 
has  a  definition,  namely 
MOVE  = 

(LAMB0A  (OBJ  0RIG  DEST) 

(ANO  [=  (LOC  OBJ)  ORIG]  [BECOME  ( LOC  OBJ)  DEST])) 


This  means  "OBJ  moves  from  ORIG  to  OEST  when  its  location  changes  from  ORIG  to  DEST."  The 

functions  LOC  and  BECOME  arc  fluents  (implicit  functions  of  lime).  It  is  possible  to  define 

BECOME  = 

(LAMBDA  (F  C) 

(ANO  [*  F  C]  [=  (NEXT  F)  C])) 
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This  means  "F  becomes  C  (at  time  i)  if  F  is  not  C  (at  time  t)  but  die  next  F  is  C."  (LOC  X)  means 

"the  location  of  X  (at  time  t)."  If  time  is  discrete,  it  is  possible  to  define  the  fluent 

NEXT  = 

(LAMBDA  (F) 

[LAMBDA  (T)  (F  (  +  T  1))]) 

This  means  "the  value  of  ( NEXT  F )  (at  time  t)  is  the  value  of  F  at  time  t+ 1.” 

In  short,  move  can  be  elaborated  down  to  a  very  primitive  level.  However,  die  knowledge  base  of 
Hearts  concepts  is  deliberately  constructed  so  that  all  higher-level  actions  that  share  a  common  sub¬ 
event  have  at  least  one  common  sub-event  at  a  higher  level  than  MOVE.  This  means  that  an 
intersection  search  for  a  common  sub-event  of  two  higher-level  actions  can  safely  stop  at  MOVE. 

So  the  only  sub-events  of  (EACH  Pi  (PLAYERS)  (PLAY-CARD  Pi))  are  {PLAY- card.  play}. 

too  next  finds  the  abstractions  of  (TAKE  ME  QS).  By  Al,  these  include 
TAKE  =  ( LAM80A  (P  C)  (MOVE  C  POT  (PILE  C))) 

The  event  move  doesn't  count,  since  it's  a  low-level  event,  so  the  only  abstraction  of 
(TAKE  ME  QS)  is  take.  Since  {PLAY-CARD,  PLAY}  and  {TAKE}  are  disjoint,  the  condition  of 
RULE57  is  satisfied.  TOO  deduces  drat  one  can’t  take  the  Queen  during  the  part  of  die  trick  when 
cards  arc  played. 

5.6.1. 2  Can’t  Take  Points  While  Cards  are  Played 

A  similar  example  occurs  in  DF;RIV6.  where  RUI.K57  is  used  to  make  die  reduction 

(DURING  [EACH  PI  (PLAYERS)  (PLAY-CARD  Pi)]  [TAKE-POINTS  ME])  ->  NIL 

The  abstractions  of  (TAKE-POINTS  ME)  are  {TAKE-POINTS,  TAKE}  by  Al,  A2,  A5,  and  the 
definition 

TAKE-POINTS  =  (LAMBOA  (P)  (FOR-SOME  C  (POINT-CARDS)  (TAKE  P  C))) 

Since  these  are  disjoint  from  {PLAY-CARD,  PLAY},  FOO  deduces  that  one  can't  take  points  during 
the  part  of  the  trick  in  which  cards  are  played. 
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5.6.1.3  Cards  Can’t  Become  Out  During  Round 

DERIV10  includes  a  proof  that  a  card  can’t  become  "out’’,  i.e.,  get  into  an  opponent's  hand,  while 

the  round  is  in  progress.  "Becoming  out"  is  first  reformulated  in  terms  of  known  actions: 

(DURING  [ROUND- IN -PROGRESS]  [CAUSE  (OUT  XI)]) 

10:5-9  -  [by  analysis]  - > 

(DURING  [ROUND-IN-PROGRESS]  [EXISTS  PI  (OPPONENTS  ME) 

(GET-CARD  PI  XI  LOCI)]) 


To  compute  the  sub-events  of  (ROUND-  IN -PROGRESS),  FOO  examines  the  definitions 
ROUND-IN-PROGRESS  = 

( LAM8DA  ()  (EACH  I  ( TR  ICK- INDICES )  (TRICK))) 

TRICK  = 

(LAMBDA  () 

(SCENARIO  (EACH  P  (PLAYERS)  (PLAY-CARD  P ) ) 

(TAKE-TRICK  (TRICK-WINNER)))) 


PLAY-CARD  => 

(LAMBDA  (P) 

(CHOOSE  (CARD-OF  P)  (LEGALCARDS  P) 
(PLAY  P  (CARD-OF  P)))) 

PLAY  = 

(LAMBDA  (P  C) 

(MOVE  C  (HAND  P)  POT)) 

TAKE-TRICK  = 

(LAMBDA  (P) 

(EACH  C  (CARDS-PLAYED)  (TAKE  P  C))) 


TAKE  = 

(LAMBDA  (PC) 

(MOVE  C  POT  (PILE  C))) 


The  sub-events  of (ROUND-IN-PROGRESS)  arc  {ROUND-IN-PROGRESS,  TRICK,  PLAY-CARD,  PLAY, 
TAKE-TRICK,  TAKE},  but  (EXISTS  PI  (OPPONENTS  ME)  (GET-CARD  PI  XI  LOC 1 ))  has  as  its  only 
absti  action 

GET-CARD  =  (LAMBDA  (P  C  ORIG)  (MOVE  C  ORIG  (HAND  P))) 

Therefore  F  OO  concludes  that  a  card  can't  become  out  while  a  round  is  in  progress. 

5.6. 1.4  Voids  Can’t  be  Undone  During  the  Round 

A  similar  problem  occurs  in  DER1V12;  show  that  a  void  can't  be  undone  while  a  round  is  in 
progress.  Since  undoing  a  void  is  not  a  named  action,  it  is  reformulated  as  one: 
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(DURING  [ROUND-IN-PROGRESS]  [UNDO  (VOID  PO  SO)]) 

12:2-10  —  [by  analysis]  — > 

(DURING  [ROUND-  IN-PROGRESS]  [EXISTS  Cl  (CARDS) 

(AND  [GET-CARD  PO  Cl  LOCI] 

[IN-SUIT  Cl  SO])]) 

The  sub-events  of  (ROUND- IN-PROGRESS)  arc  the  same  as  before,  while  according  to  A3  the 
abstractions  of  (EXISTS  Cl  (CARDS)  (AND  [GET-CARD  PO  Cl  LOCI]  [IN-SUIT  Cl  SO]))  arc 
{GET-CARD,  IN-SUIT,  =},  based  on  the  above  definition  of  GET-CARD  and  the  definition 
IN-SUIT  =  (LAMBOA  (C  SUIT)  (=  (SUIT-OF  C)  SUIT)) 

The  predicates  IN-SUIT  and  =  arc  erroneously  identified  as  actions  by  A3  as  it  applies  to  the 
conjunction  (AND  [GET-CARD  PO  Cl  LOCI]  [IN-SUIT  Cl  SO]).  Such  conjunctions  arc 
meaningful  since  actions  are  predicates  in  roo's  semantics  (§1.3. 1.3),  but  the  routine  for  finding 
abstractions  doesn’t  check  which  conjuncts  arc  actions.  This  could  easily  be  fixed  by  changing  A3  to 

A3’.  The  abstractions  of  (and  eL ...  cn)  consist  of  those  of  the  actions  among  cL ...  en. 

At  any  rate,  it  causes  no  trouble  in  this  example:  the  sets  are  still  disjoint,  and  foo  concludes  that 
a  player  who  is  void  in  a  suit  remains  void  for  the  rest  of  the  round. 


5.6.2.  Identifying  Choice-Free  Events 


Intersection  search  helps  find  the  choice  events  in  a  scenario  by  quickly  eliminating  pares  of  the 

scenario  in  which  no  choice  occurs.  This  is  illustrated  in  DERIY2,  where  FOO  finds  die  sequence  of 

choice  events  in  a  trick  (§3.3.2): 

(CHOICE  -SEQ-OF  (TAKE-TRICK  (TRICK-WINNER))) 

2:7  ---  [by  RULE308]  ---> 

NIL 


This  transformation  is  performed  by 

RULE308:  (choice-seq-of  s)  ->  nil  if  no  sub-events  of  s  arc  choice  events 


The  sub-events  of  (TAKE -TRICK  (TRICK-WINNER))  arc  {TAKE-TRICK,  TAKE},  since 

TAKE-TRICK  * 

(LAMBOA  (P) 

(EACH  C  (CAROS-PLAYED)  (TAKE  P  C))) 

TAKE  * 

( LAM80A  (P  C)  (MOVE  C  POT  (PILE  P))) 
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A  choice  event  is  an  event  of  the  form  (choose  x  S  F.x).  Since  neither  TAKE- TRICK  nor  TAKE  is  a 
choice  event,  the  choice  sequence  of  (take -TRICK  (trick -winner))  is  nil. 

5.6.3.  Finding  a  Common  Superset 

The  problem  of  finding  a  comon  superset  of  two  sets  arises  in  DERIY9  as  a  sub-problem  of 
applying  the  disjoint  subsets  method  (§2.3).  The  two  sets  are  ( CARDS- IM-HAND  PO)  and 
( CAROS-  In-su I T  SO).  The  disjoint  subsets  method  requires  a  common  superset  whose  size  will  he 
known  at  runtime.  (Problems  associated  with  representing  and  testing  such  conditions  are  discussed 
in  (§8.1.1).)  Obviously  any  two  sets  have  an  infinite  number  of  common  supersets,  of  which  the 
smallest  is  their  union.  The  know  n-size  requirement  precludes  using  the  union  in  this  case.  Thus  the 
problem  is  to  substitute  a  set  of  known  size  for 

(COMMON-SUPERSET  [CARDS- IN-HAND  PO]  [CARDS- IN -SUIT  SO]) 

The  construct  (common-superset  Sx  S.)  denotes  the  (non-unique)  set-valued  solution  S  of  the 

equation  (and  (subset  Sj  SJ  (subset  S2  S|).  The  problem  is  solved  in  DFRIV9  as  follows: 

(COMMON-SUPERSET  [CARDS- IN-HAND  PO]  [CARDS- IN-SUIT  SO]) 

9:23-24  ---  [ELABORATE  by  RULE124]  ---> 

(COMMON-SUPERSET  [SET-OF  C2  (CAROS)  (HAS  PO  C2)] 

[SET-OF  C3  (CARDS)  (IN-SUIT  C3  SO)]) 

9:25  ---  [by  RULE  199]  ---> 

(CARDS) 

Here  the  effect  of  an  intersection  search  is  simulated  by 

RULF199:  (common-superset  (set-of  x  S  PJ  (set-of  v  S  R  ])  ->  S 

It  would  be  straightforward  to  implement  an  intersection  search  procedure  for  finding  common 
supersets.  The  associated  network  would  contain  a  node  for  each  defined  set  concept.  The  node  for  a 
set  defined  as  (set-of  x  S  P  )  or  (filter  S  P)  would  be  connected  by  a  "superset-of  ’  arc  to  the  node  for 
S.  Starting  from  the  nodes  for  the  two  given  sets  and  Sv  the  search  procedure  w-ould  follow 
'‘superset-of  arcs  until  the  two  branches  of  the  search  encountered  a  common  node:  tine 
corresponding  set  would  be  a  common  superset  of  S(  and  S,.  Alternatively,  the  procedure  could 
exhaustively  find  all  defined  supersets  of  each  set,  and  return  live  intersection  of  these  two  collections. 
Some  other  process  could  then  choose  from  the  collection  of  common  supersets  the  one  best 
satisfying  problem-specific  criteria,  such  as  known  size. 


» 
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5.6.4.  Intersection  Search:  Summary 

The  key  points  about  intersection  search  emphasized  in  this  section  are: 

1.  Reducing  a  problem  to  intersection  search  through  a  precomputed  network  is  a  powerful 
technique,  since  such  a  search  can  be  performed  efficiently  (in  bounded  time). 

2.  An  unsuccessful  intersection  search  can  be  very  useful  as  a  quick  way  to  rule  out  a  possibility 
for  which  the  existence  of  a  path  is  a  necessary  condition,  even  when  the  original  problem  can't 
be  reduced  to  an  intersection  search. 

3.  The  netw  ork  representation  used  by  an  intersection  search  procedure  can  be  automatically 
extracted  from  the  definitions  of  the  concepts  corresponding  to  the  nodes. 

FOO's  intersection  search  procedures  are  not  especially  efficient  or  general.  To  test  for  the 
existence  of  a  path  between  two  nodes,  FOO  exhaustively  enumerates  the  set  of  nodes  accessible  to 
each  one  and  only  then  checks  to  see  if  the  two  sets  overlap.  For  a  large  network,  it  would  be  more 
efficient  to  check  for  intersections  while  expanding  the  accessible- node  sets.  Moreover,  the 
procedures  arc  specific  to  particular  kinds  of  problems  -  showing  an  event  is  impossible  and  deciding 
if  a  scenario  involves  choice. 

In  short,  the  interest  here  is  not  in  improved  search  algorithms,  but  in  how  methods  like 
intersection  search  can  be  mechanically  applied  to  a  given  problem.  1  showed  how  the  information 
required  to  precompute  the  nodes  and  arcs  of  the  network  for  an  intersection  search  can  be 
mechanically  extracted  from  a  set  of  concept  definitions.  To  make  this  point,  it  was  sufficient  to 
create  virtual  networks  defined  by  procedures  for  finding  die  neighbors  of  a  node;  it  was  not 
necessary  to  physically  encode  such  networks  as  separate  data  structures,  so  I  didn't.  However,  this 
additional  step  would  be  required  to  exploit  the  full  efficiency  of  intersection  search. 

5.7.  Problem  Separation 

A  very  general  strategy  for  reducing  a  problem  is  to 

Split  the  problem  into  two  or  more  separately  solvable  subproblems. 

Depending  on  how  the  subproblcms  relate  to  the  original  problem,  it  may  not  oven  be  necessary  to 
solve  them  all.  For  example,  a  proposition  can  be  disproved  by  splitting  it  into  a  conjunction  and 
disproving  one  conjunct.  Similarly,  a  goal  can  be  achieved  by  splitting  it  into  a  disjunction  and 
achieving  one  disjunct. 
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Some  problems  arc  solvable  by  a  divide- and- conquer  approach:  solve  the  subproblems  and 
combine  their  solutions  into  a  solution  of  the  original  problem.  Here,  solving  the  original  problem 
requires  solving  all  the  subproblems:  there  may  be  no  alternative  if  the  original  problem  is  not 
directly  solvable  by  available  methods.  Examples  of  dividc-and-conquer  include  splitting  a  goal  into 
conjunctive  subgoals,  or  breaking  it  down  into  alternative  contingencies,  and  generating  a  separate 
plan  for  each.  A  function  might  be  computed  by  reformulating  it  as  a  sum.  evaluating  each  term,  and 
adding  tire  results.  As  this  example  suggests,  problem  splitting  can  be  used  not  only  to  transform  a 
proposition  into  a  conjunction  or  disjunction,  but  also  to  split  a  non-boolcan  problem  into 
subproblems  related  to  the  original  problem  by  addition  or  some  other  non-logical  function. 
However,  most  of  the  examples  in  this  section  involve  logically  related  subproblcms. 

Separating  a  problem  into  subproblcms  is  a  little  like  chipping  away  built-up  ice  in  a  refrigerator: 
you  find  a  crack  you  can  fit  a  chisel  into,  and  then  hammer  away  to  widen  the  crack  until  the  whole 
thing  fractures  into  pieces.  In  both  cases,  the  choice  of  a  good  starting  point  depends  on  the  specific 
problem  and  affects  the  ease  or  difficulty  of  propagating  the  split  all  the  way  through.  In  problem 
separation,  the  initial  split  is  typically  provided  by  a  domain-specific  rule  or  definition,  while  more 
general  methods  are  used  to  propagate  it.  Actually,  defrosting  is  a  much  safer  way  to  get  rid  of  built- 
up  ice  in  your  freezer,  since  the  chisel  method  runs  the  risk  of  puncturing  a  freezer  line,  which  costs 
more  to  repair  than  replacing  the  refrigerator,  as  I  found  out  the  hard  way.  1  mention  this  because 

1.  A  dissertation  should  communicate  useful  information,  and 

2.  It  illustrates  a  disadvantage  of  empirical  discovery  relative  to  analytic  methods  (§8.1.7). 

In  general,  problem  separation  works  by  splitting  some  term  in  die  problem  and  men  propagating 
the  split  up  to  successively  higher  levels  of  the  problem  description  so  as  to  transform  it  into  a 
collection  of  separate  subproblcms  -  separate  in  me  sense  that  different  methods  can  be  used  on  each 
one,  although  assumptions  made  in  solving  one  may  constrain  the  solution  of  the  others  (§5.4.3). 
This  problem  splitting  scenario  can  be  described  more  precisely  as  follows: 

1.  Reformulate  a  problem  (P  ...)  in  terms  of  a  function  f:  (P  ...)  ->  (P  ...  (f...  e  ...) ...). 

2.  Split  a  n  argument  of  ('into  a  list  of  components:  (f ...  c  ...)  ->  (f ...  [g  e,  ...  c  ] ...). 

3.  Propagate  the  split  upward:  (f ...  [g  Cj  ...  ej  ...)  ->  (g‘  [f  ...  e;  ...]  ...  [f  ...  e  ...]). 

4.  Analyze  each  component  (P  ...  C|  ...)  separately. 

The  genera!  concept  of  problem  splitting  has  some  interesting  specializations: 

1.  Conjunctive  subgoaling 
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a.  Partial  matching 
2.  Case  analysis 

a.  Condition  factoring 

These  can  be  characterized  as  special  eases  of  the  general  problem  splitting  transformation 
(f ...  e ...)  ->  (g‘  [f  ...  ej  ...]•••  [f  -  en  ...]) 

Conjunctive  subgoaling  corresponds  to  the  ease  where  g'  =  AND,  and  f,  f  are  predicates  P,  P-: 
tP  ...  [g  e, ...  en] ...)  ->  (and  [?' ...  ^  ...] ...  [P* ...  cn  ...]) 

If  the  initial  proposition  represents  a  goal  to  be  achieved.  each  conjunct  represents  a  subgoal.  One 
form  of  conjunctive  subgoaling  already  discussed  is  partial  matching  (§5.3),  where  f  is  a  reflexive 
binary  relation  R,  and  f  is  the  equality  relation: 

(R  [g  e, ...  ej  [g  ...  ej)  •>  (and  [=  e,  ef] ...  {=  cn  ej) 

Case  analysis  is  problem  splitting  with  g'  =  OR: 

( P...  [ger..cn]  ...)->  (or  [P* ...  eA ...] ...  [P'  ...cn...j) 

I-’ach  disjunct  represents  a  subclass  of  the  situations  characterized  by  the  initial  proposition.  One 
kind  of  case  analysis,  which  I'll  call  condition  factoring  for  want  of  a  better  term,  involves  splitting  a 
problem  e  into  two  cases:  solving  the  problem  when  some  condition  C  is  true,  and  solving  it  when  C 
is  false.  If  e  is  a  proposition  to  be  evaluated  or  achieved,  factoring  it  with  respect  to  C  corresponds  to 
one  of  the  following  transformations: 

e  ->  (and  [  =  >  C  ej  [  =  >  ( not  C)  e]) 
e  ->  (or  [and  C  e]  [and  (not  C)  c[) 
e  ->  t if  C  ec  e_c) 

Fach  transformation  splits  die  problem  into  two  separate  subproblems.  The  last  one  is  used  if  e  is 
not  a  proposition,  since  IF,  unlike  and  and  OR.  can  take  expressions  other  than  propositions.  The 
construct  (if  C  ec  c_c)  factors  e  into  two  contexts,  one  assuming  C.  die  other  assuming  ~C.  Unlike 
AND  and  OR.  IF  takes  a  fixed  number  of  arguments,  and  dieir  order  is  important.  An  alternative 
syntax  without  this  restriction  is  the  LISP  construct  tcond  [C  ec]  [~C  e  M)  [McCarthy  63).  The  IF 
construct  corresponds  to  a  special  case  of  CONO  with  two  complementary  conditions. 
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The  rest  of  this  section  is  organized  as  follows.  (§5.7.1)  illustrates  the  problem  splitting  scenario 
using  two  detailed  examples  of  case  analysis.  The  next  two  sections  describe  condition 
factoring  (§5.7.2)  and  conjunctive  subgoaling  (§5.7.3).  (§5.7.4)  presents  FOO's  rules  for  introducing 
initial  problem  splits,  and  (§5.7.5)  lists  the  rules  used  to  propagate  such  splits.  (§5.7.6)  briefly 
discusses  the  technique  of  merging  related  subproblcms  into  a  single  problem.  Finally,  (§5.7.7)  draws 
some  conclusions  about  problem  splitting  in  general. 

5.7.1.  Case  Analysis 

The  general  scenario  for  case  analysis  consists  of  the  following  steps: 

1.  Reformulate  an  expression  in  terms  of  a  predicate  R. 

2.  Split  an  argument  of  R  into  a  list  of  components. 

3.  Propagate  the  split  upward  to  produce  a  disjunction. 

4.  Analyze  each  case  of  the  disjunction  separately,  perhaps  eliminating  it. 

This  scenario  is  illustrated  in  DF.RIV6  in  the  analysis  of  how  to  avoid  taking  points  during  a  trick. 
The  problem  is  split  into  two  cases: 

1.  Taking  points  while  cards  are  being  played 

2.  Taking  points  when  the  winner  takes  the  trick 

The  first  case  is  found  to  be  impossible,  and  the  second  case  is  reduced  to  a  simpler  condition. 

The  initial  problem  is  first  reformulated  in  terms  of  the  predicate  DURING: 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

6 ; 2  ---  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (NOT  (DURING  [TRICK]  [TAKE-POINTS  ME]))) 


The  first  argument  to  DURING  is  then  split  into  a  scenario  of  two  components: 

(TRICK) 

6:3  ---  [ELA80RATE  by  RULE124]  ---> 

(SCENARIO  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)] 
[TAKE-TRICK  (TRICK-WINNER)]) 


The  predicate  on  the  scenario  is  reformulated  as  a  disjunction  of  predicates  on  the  components: 


238 


§5.  Analysis  Methods 


(DURING  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 
( TAKE-TRICK  (TRICK-WINNER) )] 
(TAKE-POINTS  ME)) 

8:4  ---  [by  RULE284]  ---> 

(OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 
(TAKE-POINTS  ME)] 

[OURING  (TAKE-TRICK  (TRICK-WINNER)) 

(TAKE-POINTS  ME)]) 


This  step  is  performed  by  a  general  aile  about  homomorphisms: 

RULF.284:  (f ...  [g  e,  ...  ej  ...)  ->  (g‘  [f ...  et ...] ...  (f ...  en ...])  if  f  is  homomorphic  w.r.t.  g.  g’ 

Here  f  =  DURING,  g  =  SCENARIO,  e,  =  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)),  e2  = 
(TAKE-TRICK  (TRICK-WINNER)  ),  and  g  =  OR. 


This  transformation  propagates  the  split  upward  one  level  in  the  current  expression,  producing  a 
disjunction  whose  terms  can  be  analyzed  individually.  One  case  is  eliminated  by  intersection 
search  (§5.6): 

(DURING  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)] 

[TAKE-POINTS  ME]) 

6:5  ---  [COMPUTE  by  RULE57]  ---> 

NIL 


The  other  case  is  reduced  by  partial  matching  (§5.3): 

(OURING  [TAKE-TRICK  (TRICK-WINNER)] 

[TAKE-POINTS  ME]) 

6 : 7-22  —  [REDUCE  by  partial  matching,  analysis] - > 

(AND  [«  (TRICK-WINNER)  ME]  [TR ICK-HAS- POINTS ] ) 


Thus  case  analysis  transforms  the  initial  problem  into  a  disjunction  of  separately  analyzabtc 
propositions,  each  of  which  is  treated  using  the  methods  suited  to  it  (intersection  search  and  partial 
matching,  respectively). 


Case  analysis  is  also  used  in  DF.RIV4  in  the  course  of  applying  the  pigeon-hole  principle  to  the 
problem  of  deciding  whether  the  Queen  is  out.  The  pigeon-hole  principle  implies  that  the  Queen  is 
in  the  hand  of  one  of  player  mb's  opponents  iff  it's  not  at  any  other  location: 

(OUT  QS ) 

4:2-6  —  [by  analysis]  — > 

(IN  (LOC  QS)  (PROJECT  HANO  (OPPONENTS  ME))) 

4:7  ---  [by  RULE159]  ---> 

(NOT  (IN  (LOC  QS) 

(DIFF  (RANGE  LOC)  (PROJECT  HAND  (OPPONENTS  ME))))) 
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The  initial  split  in  the  problem  comes  from  partitioning  the  set  of  possible  locations: 

(RANGE  LOC) 

4:9  — -  [ENUMERATE  by  RULE163]  — > 

(PARTITION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 


This  step  uses  a  Hcarts-spccific  "fact-rule”  (§1.3.3)  to  simulate  a  type  mechanism  and  subset 
hierarchy: 

RULE163:  (range  !oc)  ->  (partition  (hands  (players))  (piles  (players))  (set  deck  pot  hole)) 


To  propagate  the  split  upward,  the  0 IFF  operator  must  be  eliminated.  To  do  this,  a  set  identity  is 

applied  after  putting  the  problem  in  the  right  form: 

(OIFF  (PARTITION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

[PROJECT  HAND  (OPPONENTS  ME)]) 

4:10-14  -  [by  analysis]  - > 

(DIFF  (UNION  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

[DIFF  (HANDS  (PLAYERS))  (SET  (HAND  ME))]) 

4:15  ---  [by  RULE  164]  ---> 

(UNION  [DIFF  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

(HANDS  (PLAYERS))] 

[INTERSECT  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

(SET  (HAND  ME))]) 


The  set  identity  is  expressed  by 

RUL.E164:  (diffSj  [diiTS?  S^J)  ->  (union  [diffS,  S2]  [intersect  Sj  S^]) 


RULE164  introduces  a  two-way  split  in  that  die  two  terms  in  (UNION  [.  .  .]  [...])  can  be 

treated  separately.  The  first  term  is  simplified: 

(DIFF  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

(HANDS  (PLAYERS))) 

4  :  16- Id  ---  [SIMPLIFY  by  RULE  19]  ---> 

(UNION  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 


The  second  term  is  factored  into  two  cases  by 
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RULE-165:  (intersect  S  [sctc])  ->  (if  [in  c  S]  [sctc]  nil) 


The  two  cases  correspond  to  whether  or  not  ( HAND  ME )  is  among  the  enumerated  locations: 

(INTERSECT  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

[SET  (HAND  ME)]) 

4:20  ---  [by  RULE  165 ]  ---> 

(IF  [IN  (HAND  ME) 

(UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE))] 

[SET  (HAND  ME)] 

NIL) 


The  original  3-way  split  is  now  propagated  into  the  factoring  condition  (IN  . . . ): 

(IN  (HAND  ME) 

'  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE))) 

4:21  ---  [by  RULE284]  ---> 

(OR  [IN  (HAND  ME)  (HANDS  (PLAYERS))] 

[IN  (HAND  ME)  (PILES  (PLAYERS))] 

[IN  (HAND  ME)  (SET  DECK  POT  HOLE)]) 


The  first  term  of  this  disjunction  is  true,  so  the  whole  disjunction  is  true.  Since  the  factoring 

condition  is  true,  the  conditional  expression  reduces  to  the  “true"  branch: 

(IF  T  (SET  (HAND  ME))  NIL) 

4:26  ---  [SIMPLIFY  by  RULE  185 ]  ---> 

(SET  (HAND  ME)) 


Now  that  DIFF  is  gone,  a  bit  of  simplification  allows  the  original  split  to  be  propagated: 
(IN  (LOC  QS) 

(UNION  [UNION  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)] 

[SET  (HAND  ME)]) 

4:28-29  ---  [SIMPLIFY  by  RULE  177  ,  RULE  187 ]  ---> 

(IN  (LOC  QS) 

(UNION  (SET  DECK  POT  HOLE  (HAND  ME))  (PILES  (PLAYERS)))) 

4:31  ---  [by  RULE284]  ---> 

(OR  [IN  (LOC  QS)  (SET  DECK  POT  HOLE  (HAND  ME))] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 

4:32-33  -  [by  RULE182,  simplification]  - > 

(OR  [=  (LOC  QS)  DECK] 

[*  (LOC  QS)  POT] 

[=  (LOC  QS)  HOLE] 

[=  (LOC  QS)  (HAND  ME)] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 


( 
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The  propagation  at  step  4 : 3 1  is  performed  by 

RULE284:  (f...  [g  ct ...  ej  ...)  ->(g'  [f ...  et  ...J ...  [f ...  cn  ...])  if  f  is  homomorphic  w.r.t.  g,  g’ 

Here  f  =  IN.  g  =  UNION,  g’  =  OR.  The  subsequent  propagation  at  step  4:32  is  performed  by 
RULE182:  (in  e (set e; ...  eQ))  ->  (or  [=  c  cj ...  [=  e ej) 

The  problem  has  now  been  split  into  five  cases  corresponding  to  the  terms  of  tine  disjunction.  The 
rest  of  die  derivation  treats  each  one  separately,  using  different  methods.  The  DECK  case  is 
eliminated;  the  POT  and  ( HAND  ME)  cases  are  reformulated  in  terms  of  observable  predicates;  the 
(PILES  (PLAYERS))  case  is  reformulated  in  terms  of  a  remembered  event;  and  the  HOLE  case 
cannot  usually  be  detected,  but  is  unlikely  enough  to  be  ignored  (assumed  false)  (§2.9.3); 

(NOT  (OR  [IN-POT  OS]  (AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  OS])) 

Problem  separation  was  used  more  than  once  in  this  example.  First  the  problem  was  split  by 
partitioning  (RANGE  LOC).  Applying  die  differcncc-of-differences  identity  made  two  copies  of  this 
spliL  The  first  copy  was  simplified  by  removing  (HANDS  (PLAYERS))  from  die  partition.  The 
second  copy  was  incorporated  in  a  factoring  condition  and  propagated  up  to  split  that  condition  into 
a  disjunction.  A  term  of  the  disjunction  was  proved,  reducing  die  factoring  condition  to  true,  and  the 
false  branch  was  discarded.  This  enabled  the  original  split  to  be  propagated  upward  dirougli  the 
overall  expression  so  as  to  form  a  disjunction  of  separately  treatable  cases. 

5.7.2.  Condition  Factoring 

Condition  factoring  is  case  analysis  with  two  cases,  one  when  some  factoring  condition  C  is  true,  the 

other  when  C  is  false,  as  illustrated  in  DERIV14; 

(=  (^OCCURRENCES  ( NEXT  (CLIMAX  CANTUS- 1 ) )  (NEXT  CANTUS-1))  1) 

14:8  ---  [by  RULE276]  — > 

(OR  [ANO  [NOT  (CHANGE  (CLIMAX  CANTUS-1))] 

[=  (^OCCURRENCES  (CLIMAX  CANTUS- 1)  (NEXT  CANTUS-1))  1]] 

[AND  [CHANGC  (CLIMAX  CANTUS-1)] 

[=  { (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1)) 

(NEXT  CANTUS-1)) 

1]]) 

Here  C  =  (CHANGE  (CLIMAX  CANTUS-1) )  is  given  by  (change  e)  in 

RULE276;  P(neu e)  ->  (or  [and  [not  (change  o)J  P.J  [and  [change  e]  P(ncx[ e)]) 

Factor  a  goal  that  depends  on  an  expression’s  next  value  according  to  whether  1  changes. 
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In  litis  example,  the  goal  of  having  the  climax  tone  occur  exactly  once  is  factored  into  two  eases  (1 

and  2)  according  to  whether  die  climax  changes  on  the  next  note.  Case  1  is  itself  factored: 

(*  [^OCCURRENCES  (CLIMAX  CANTUS-1)  (NEXT  CANTUS-1)]  1) 

14:10-19  —  [by  analysis]  — > 

(=  [+  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

(#  [SET-OF  XI  (LIST  (NEXT  NOTE)) 

(=  XI  (CLIMAX  CANTUS-1))])] 

1) 

14:20-21  ---  [by  RULE121 .  SIMPLIFY  by  RULE178]  ---> 

(=  [+  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

(#  [IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(SET  (NEXT  NOTE)) 

NIL])] 

1) 


Ihe  factoring  condition  ( =  (NEXT  NOTE)  (CLIMAX  CANTUS-1 ) )  is  given  by  P  in 

el 

RULK121:  (set-of  x  (collection  ej ...  cn)  Px)  ->  (union  [if  {ej  nit] ...  [if  Pc  {cn}  nil]) 

C1  n 


Propagating  the  conditional  split  up  one  level  permits  some  simplification: 

(#  [IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 
(SET  (NEXT  NOTE)) 

NIL]) 

14:22  ---  [by  RULE287]  ---> 

(IF  (  =  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

[#  (SET  (NEXT  NOTE))] 

[#  NIL]) 

14:23-24  ---  [SIMPLIFY  by  RULE283 ,  RULE289]  ---> 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

1 

0) 


The  split  is  propagated  by 

RULE287:  (f ...  (if  C  ec  e„cj ...)  ->  (if  C  [f ...  ec  ...)  [f ...  e_c  ...]) 


This  rule  is  applied  again  to  propagate  the  split  up  another  level: 

(*  (  +  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

[IF  (*  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  1  0]) 

1) 

14:25  ---  [by  RULE287]  ---> 

(IF  ( =  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

[=  (+  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)  1] 
[=  (+  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0)  1]) 


This  adds  enough  context  to  simplify  one  branch: 
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14:26 


(=  (+  ((/OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0)  1) 
---  [SIMPLIFY  by  RULF343]  -— > 

(=  ((/OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1) 


The  added  context  also  makes  it  possible  to  eliminate  the  other  branch: 

(=  (+  ((/OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)  1) 
14:27  ---  [REDUCE  by  RULE290]  ---> 

(=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0) 
14:29-30  ---  [by  analysis]  ---> 

(NOT  (IN  (CLIMAX  CANTUS-1)  CANTUS-1)) 

14:31-34  ---  [by  analysis]  ---> 

NIL 


The  surviving  branch  is  conjoined  widi  the  negation  of  the  factoring  condition: 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

NIL 

(*  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)) 
14:36  ---  [RECOGNIZE  by  RULE294]  ---> 

(AND  [=  ((/OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 
[NOT  (-•  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]) 


This  reduction  is  performed  by 

RU1.F.294:  (if  C  nil  F)  ->  (and  P  [not  C]) 


The  idea  is  dial  the  factoring  condition  C  must  be  false  to  satisfy  the  condition  (ifC  nil  P). 


Condition  factoring  is  also  used  to  analyze  Case  2,  where  the  climax  changes  when  die  next  note  is 
added: 


(AND  [CHANGE  (CLIMAX  CANTUS-1)] 

[=  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1)) 
(NEXT  CANTUS-1)) 

1]) 

14:53-63  —  [by  analysis]  — > 

(AND  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[=  (+  ((/OCCURRENCES  (NEXT  NOTE)  CANTUS-1) 
(H  [SET-OF  X4  (LIST  (NEXT  NOTE)) 

(=  X4  (NEXT  NOTE))])) 

1]) 


(#  [SET-OF  X4  (LIST  (NEXT  NOTE)) 

(=  X4  (NEXT  NOTE))])) 

14:64-65  ---  [by  RULE121 .  SIMPLIFY  by  RULE  173]  ---> 

(#  [IF  (=  (NEXT  NOTE)  (NEXT  NOTE)) 

(SET  (NEXT  NOTE)) 

NIL]) 


The  suggested  factoring  condition  is  P„  in 

el 
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RULE121:  (set-of  x  (collection  er ...  cn)  Px)  ->  (union  [if  Pg  {ej  nil] ...  [if  Pc  {en}  nil]) 

1  n 

'Ihis  condition  reduces  immediately  to  true: 

(=  (NEXT  NOTE)  (NEXT  NOTE)) 

14:66  ---  [EVAL  by  RULE  179]  ---> 

T 


This  makes  it  possible  to  eliminate  the  second  branch  without  propagating  the  split: 

(IF  T  (SET  (NEXT  NOTE))  NIL) 

14:67  ---  [SIMPLIFY  by  RULE185]  ---> 

(SET  (NEXT  NOTE)) 


This  in  turn  enables  considerable  simplification: 

(AND  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[=  (+  (^OCCURRENCES  (NEXT  NOTE)  CANTUS-1) 

{#  (SET  (NEXT  NOTE)))) 

1]) 

14:68-69  ---  [COMPUTE  by  RULE288 ,  REDUCE  by  RULE290]  ---> 

(ANO  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[=  (/^OCCURRENCES  (NEXT  NOTE)  CANTUS-1)  0]) 

14:70-72  ---  [ELABORATE  by  RULE124 ,  RECOGNIZE  by  RULE291-292]  ---> 
(AND  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[NOT  (IN  (NEXT  NOTE)  CANTUS-1)]) 

14:73-79  —  [by  analysis:  second  conjunct  implied  by  first]  — > 
(HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 


The  form  of  the  solution  reflects  the  original  factoring  into  two  cases: 

(OR  [AND  [«  (//OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 
[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]] 

[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 


In  this  example,  condition  factoring  was  used  to  split  the  initial  expression  into  two  cases.  Case  I 
was  itself  split  into  two  branches  by  factoring  a  subexpression  nested  a  few  levels  deep.  Propagating 
the  split  up  one  level  permitted  some  evaluation;  propagating  it  up  one  more  level  permitted  one 
branch  to  be  reduced  to  nil.  This  meant  that  the  factoring  condition  had  to  be  true  for  Case  I  to  be 
satisfied.  Case  2  also  contained  a  factorable  nested  subexpression.  Here  the  factoring  condition 
reduced  to  true  without  any  propagation.  This  reduced  the  factored  subexpression  to  one  branch, 
which  in  turn  allowed  Case  2  to  be  simplified  considerably. 


§5.7.3.  Conjunctive  Subgoaling 
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Sometimes  a  problem  is  solved  by  splitting  it  into  a  conjunction  of  separately  solvable 

subproblcms.  In  DF.RIV3  the  problem  of  flushing  the  Queen  is  split  into  two  subproblems: 

(=  (LEGALCARDS  ( QSO) )  (SET  QS ) ) 

3:12  ---  [ELABORATE  by  RULE340]  ---> 

(AND  [SUBSET  (LEGALCARDS  (QSO))  (SET  QS)] 

[SU8SET  (SET  QS)  (LEGALCARDS  (QSO))]) 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))) 

3:13-19  —  [by  analysis]  - > 

(LEGAL  (QSO)  QS) 

3:20-35  —  [assuming  spades  are  led]  — > 

T 

(SUBSET  (LEGALCARDS  (QSO))  (SET  QS)) 

3:37-97  —  [by  analysis]  — > 

(UNTIL  ( PLAYEO i  QS )  (ACHIEVE  (LEAD-SPADE  ME))) 


First  the  subproblcm  of  making  the  Queen  legal  for  player  (QSO)  is  satisfied  by  assuming  spades 
are  led.  Then  Lhc  subproblem  of  ensuring  that  (QSO)  has  no  legal  cards  besides  the  Queen  is  solved 
by  constructing  a  plan  to  keep  leading  spades.  The  initial  problem  is  split  by  applying 

RU  LF340:  ( =  e}  c,)  ->  (and  [R  Cj  c2]  [R  e.  ej), 

where  R  is  die  standard  partial  ordering  on  the  domain  of  eL  and  e2 

Here  R  =  SUBSET,  a  partial  ordering  on  sets.  The  “standard"  partial  orderings  include  SUBSET  for 

sets.  =>  for  propositions,  and  >=  for  numbers.  The  rule  is  used  in  DHR1VL3  with  R  =  >*  to  split  a 

constraint  on  the  generated  tone  sequence  PROJECT  linto  a  conjunction  of  two  terms: 

(=  ( ^OCCURRENCES  CLIMAX1  PR0JECT1)  1) 

13:83  ---  [ELABORATE  by  RULE340]  ---> 

(AND  [>=  ( ^OCCURRENCES  CLIMAX1  PR0JECT1)  1] 

[>=  1  ( ^OCCURRENCES  CLIMAX1  PROJECT  1)3) 

(>=  ( ^OCCURRENCES  CLIMAX1  PROJECT1)  1) 

13:84-86  —  [by  analysis]  — > 

(IN  CLIMAX  1  PROJECT  1 ) 

(>=  1  (^OCCURRENCES  CLIMAX1  PR0JECT1)) 

13:87  ---  [by  RULE153]  ---> 

(=<  ((^OCCURRENCES  CLIMAX1  PROJECTl)  1) 


The  heuristic  search  for  a  sequence  satisfying  the  constraint  can  be  refined  by  moving  the  first  term 
to  the  path-order  (§3.5.5.3)  and  converting  the  second  term  into  a  step-test  (§3. 5. 3.6),  while  die 
constraint  as  first  expressed  can’t  be  moved  earlier  in  the  search. 


Doth  examples  exhibit  a  "divide-and-conqucr”  approach:  although  no  methods  may  apply 
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directly  to  the  original  problem,  each  subproblem  can  be  solved  by  a  method  specifically  appropriate 
to  it. 


5.7.4.  Making  an  Initial  Split 

The  first  step  in  separating  a  problem  is  to  split  some  part  of  it  into  a  function  of  two  or  more 
components,  such  as  a  conjunction,  disjunction,  sum,  list,  or  set.  Not  just  any  function  of  more  than 
one  argument  will  do;  it  must  be  possible  to  propagate  the  split  far  enough  to  separate  the  problem 
into  subproblcms  each  of  which  involves  only  one  of  the  components. 


Usually  the  initial  split  is  made  by  expanding  the  definition  of  a  function  used  in  the  problem. 
This  is  clear  when  the  definition  contains  a  conjunction,  as  illustrated  in  DERIV3: 

{LEGAL  ( QSO)  QS) 

3:20  ---  [ELABORATE  by  RULE  124]  ---> 

(ANO  [HAS  (QSO)  QS] 

[=>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 

[NEQ  ( SUIT -OF  QS)  H])] 

[»>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 

[IN-SUIT  QS  (SUIT-LED)])]) 


Another  conjunctive  definition  is  expanded  to  introduce  a  split  in  DERIV13: 

(LEGAL-CANTUS!  PROJECT1) 

13:16  ---  [ELABORATE  by  RULE  124 ]  ---> 

(ANO  [IN  (tt  PROJECT  1 )  (L8:U8  8  16)] 

[FORALL  INTERVAL1  (  INTERVALS-OF  PROJECT1) 
(USABLE-INTERVAL!  INTERVAL1 ) ] 

[=<  (MELOOIC-RANGE  PROJECT1)  (MAJOR  10)] 

[=  (^OCCURRENCES  (CLIMAX  PROJECT  1 )  PROJECTl)  1]) 


The  expanded  definition  may  be  based  on  an  ordered  list-like  construct,  as  in  DER1V6: 

(TRICK) 

6:3  ---  [ELABORATE  by  RULE  124]  ---> 

(SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 


Or  it  may  be  an  unordered  collection,  as  in  DERIV4: 

(RANGE  LOC) 

4:9  ---  [ENUMERATE  by  RULE  163]  -  — > 
(PARTITION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 


mi  i  ■" , 
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Filch  example  above  involves  a  homogeneous  function,  Le.,  its  arguments  are  all  of  the  same  type  -- 
propositions,  events,  or  sets.  Some  heterogeneous  functions  have  homogeneous  equivalents: 

(the  x  S  Px)  is  equivalent  to  "the  x  |  (and  [in  x  S]  P  )” 

(set-of  x  S  Px)  is  equivalent  to  {x  |  (and  [in  x  S]  P  )} 

(filter  S  P)  is  equivalent  to  (intersect  S  {x  |  P  }) 


t  Splits  can  be  introduced  by  plugging  in  definitions  of  such  functions,  as  illustrated  below: 

(CARDS- IN-SUIT-LED  CARDS-PLAYED1 ) 

2:78  ---  [ELABORATE  by  RULE  124]  ---> 

(SET-OF  C 19  CARDS -PLAYE01  (*  (SUIT-OF  C19)  (SUIT-LED))) 
(LEGALCARDS  (QSO) ) 

-  3:16  ---  [ELABORATE  by  RULE124]  ---> 

(SET-OF  Cl  (CARDS)  (LEGAL  (QSO)  Cl)) 

(WINNING-CARD) 

5:16  ---  [ELABORATE  by  RULE124]  ---> 

(HIGHEST- IN-SUIT -LED  (CARDS- PLAYED) ) 

5:17  ---  [ELABORATE  by  RULE124]  ---> 

(HIGHEST  (CARDS- IN -SUIT-LED  (CARDS-PLAYED) ) ) 

5:18  ---  [ELABORATE  by  RULE124]  ---> 

(THE  C2  (CARDS-IN-SUIT-LED  (CARDS-PLAYED)) 

(FORALL  XI  (CARDS-IN-SUIT-LED  (CARDS-PLAYED)) 

(NOT  (HIGHER  XI  C) ) ) ) 

(CARDS-IN-SUIT-LED  (CARDS-PLAYED)) 

5:20  ---  [ELABORATE  by  RULE  124]  ---> 

(FILTER  (CARDS-PLAYED)  IN-SUIT-LED) 

(TRICK-WINNER) 

6:24  ---  [ELABORATE  by  RULE124]  ---> 

(PLAYER-OF  (WINNING-CARD)) 

6:25  --•■  [ELABORATE  by  RULE  124]  ---> 

(THE  P2  (PLAYERS)  (*  (CARO-OF  P2)  (WINNING-CARD))) 

(CLIMAX  PROJECT  1 ) 

13:60  ---  [ELABORATE  by  RULE  124]  ---> 

(HIGHEST  PROJECT  1 ) 

13:61  ---  [ELABORATE  by  RULE124]  ---> 

,  (THE  Cl  PROJECT  1  (FORALL  XI  PROJECT1  (NOT  (HIGHER  XI  Cl)))) 

( ^OCCURRENCES  (CLIMAX  CANTUS-1)  (LIST  (NEXT  NOTE))) 

14:19  ---  [ELABORATE  by  RULE  12 4]  ---> 

(#  (SET-OF  XI  (LIST  (NEXT  NOTE))  (=  XI  (CLIMAX  CANTUS-))))) 


♦ 


Other  rules  that  introduce  splits  are  listed  below  with  examples  of  their  use. 


» 


RULF.256:  (P  ...  [fs]  ...)->  (and  [=  (f  s)  c]  [P  ...  c  ...]), 

where  c  is  to  be  selected  from  (range  0  before  s  is  constructed  (§2.12.1.1) 
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(ACHIEVE  (=  (^OCCURRENCES  [CLIMAX  CANTUS]  CANTUS)  1) 

13:58  ---  [RESTRICT  by  RULE256]  ---> 

(ACHIEVE  (AND  [=  (CLIMAX  CANTUS)  CLIMAX!] 

[=  (^OCCURRENCES  CLIMAX1  CANTUS)  1])) 

ASSUMING  (SELECT  CLIMAX1  (TONES)) 

RULF.274:  (prefix  s  (4-  i  1))  ->  (append  (prefix  s  i]  [list  (nth  s  (  +  i  l))j) 

(PREFIX  CANTUS  (+  J  1)) 

14:12  ---  [ELABORATE  by  RULE  124 ]  ---> 

(APPENO  [PREFIX  CANTUS  J]  [LIST  (NTH  CANTUS  (+  J  1))]) 

RULE276:  P  t  ->  (or  (and  (not  (change  c))  PJ  [and  (change  e)  P  u c)])  (§5.7.2) 

(=  ( ^OCCURRENCES  [NEXT  (CLIMAX  CANTUS-1)]  (NEXT  CANTUS-1))  1) 

14:8  ---  [by  RULE276]  ---> 

(OR  [AMO  [NOT  (CHANGE  (CLIMAX  CANTUS-1))] 

[*  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  (NEXT  CANTUS-1))  1]] 
[AND  [CHANGE  (CLIMAX  CANTUS-1)] 

[«  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1)) 

(NEXT  CANTUS-1)) 

1]]) 

RULE338:  (HSM  with  (path-order :  (lambda  (s)  Ps))) 

->  (HSM  with  tstep-order :  (lambda  (i  c)  P|appcnd s (Ust c)j))) 
wheresj+l  =  c  (§3.4.3) 

( HSMl  WITH  (PATH-ORDER  : 

(LAMBDA  (CARDS-PLAYE01) 

(HAVE-POINTS  CAROS-PLAYED  1 ) ) ) ) 

2:101  ---  [REFINE  by  RULE338 ]  ---> 

HSMl  <*  STEP-ORDER  : 

(LAMBDA  (PI  C21) 

(HAVE-POINTS  [APPENO  CARDS  -  PLAYED  1  (LIST  C21 )  ]) ) 

RU1.F.340:  ( =  e,  c2)  ->  (and  [R  e,]  [R  e,  cj), 

where  R  is  the  standard  partial  ordering  on  the  domain  of  ct  and  e.,  (§5.7.3) 

(«  (LEGALCARDS  (QSO))  (SET  QS ) ) 

3:12  ---  [ELABORATE  by  RULE340]  ---> 

(AND  [SUBSET  (LEGALCAROS  (QSO))  (SET  QS)] 

[SUBSET  (SET  QS)  (LEGALCAROS  (QSO))]) 

(■  ( ^OCCURRENCES  CLIMAX1  PROJECT  1 )  1) 

13:83  ---  [ELABORATE  by  RULE340]  ---> 

(AND  [>«  ( ^OCCURRENCES  CLIMAX1  PROJECT1)  1] 

[>»  1  { ^OCCURRENCES  CLIMAX1  PROJECT1)]) 

RUI.H344:  (undo  ( =  e  v))  ->  (and  (=  e  v]  (become  e  v'J) 

(UNOO  («  (LOC  C3 )  (HAND  (QSO))) 

3:49  ---  [by  RULE344 ]  ---> 

(AND  [*  (LOC  C 3)  (HAND  (QSO))]  [BECOME  (LOC  C3)  LOC3]) 


RULE356:  P  ->  (or  [was-during (current  A)  (cause  P)]  [before  (current  A)  P])  (§2.4.1) 

» 
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(AT  QS  (PILE  P3 ) ) 

4:47  ---  [by  RULE356]  ---> 

(OR  [WAS-OURING  (CURRENT  ROUND- IN-PROGRESS) 

(CAUSE  (AT  QS  (PILE  P3 } ) ) ] 

[BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (AT  QS  (PILE  P3) )]) 

RULH370:  (#  (set-ofx  S  Px))  -> 

(-  [#  (sct-of  x  5  (before  (Current  A)  Px))] 

[#  (sct-of  x  S  (was-during  (Current  A)  (undo  Px)))]), 
provided  P  cannot  become  true  during  events  of  type  A  (§2.4.3) 

(#  (SET-OF  XI  ( CARDS  - IN-SU IT  SO)  (OUT  XI))) 

10:4-12  ---  [by  RULE370]  -— > 

(-  [#  (SET-OF  XI  (CARDS- IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND- IN- PROGR ESS )  (OUT  XI)))] 

[tf  (SET-OF  XI  (CmRDS-IN-SUIT  SO) 

(WAS-OURING  (CURRENT  ROUND-IN-PROGRESS) 

(UNDO  (OUT  XI))))]) 

RULF380:  (=  [forall  x  St  PJ  [forall  y  S,  R  ])  ->(=  R  ,  (or  P  [in  y  (diffS,  St)])  (§5.3.4) 

(  =  [FORALL  14  ( LB : UB  2  (#  PRO JECT 1 ) ) 

(USABLE-INTERVAL! 

(INTERVAL  ( PROJECT  1  (-  14  1))  (PROJECT1  14)))] 

[FORALL  II  (INDICES-OF  PROJECT1)  Ql] ) 

13:31  ---  [REDUCE  by  RULE330 ]  ---> 

(=  Ql  (OR  [USABLE-INTERVAL! 

(INTERVAL  ( PROJECT  1  (-  II  1))  (PROJECT1  II))] 

[IN  II  (DIFF  (INDICES-OF  PR00ECT1) 

( LB  : UB  2  (#  PR0JECT1 ) ) ) ] ) ) 

RUI.F385:  (set-of  x  S  (or ...  P  ...))  ->  (if  P  S  (set-of  x  S  (or ...)))  if  P  is  independent  of  x 

(SET-OF  NOTE  1  (TOMES) 

(OR  [USABLE-INTERVAL! 

(INTERVAL  ( PROJECT  1  (-  II  1))  N0TE1 ) ] 

[■  II  1])) 

13:53-54  ---  [by  RULE385 ,  SIMPLIFY  by  RULE  178]  ---> 

(IF  (=  II  1) 

(TONES) 

(SET-OF  NOTE1  (TONES) 

(USABLE-INTERVAL! 

(INTERVAL  ( PROJECT  1  (-  II  1))  NOTE1 ) ) ) ) 

RULE389:  (HSM  with  (path-test :  (lambda  (s)  P$))) 

->  (HSM  with  (step-test :  (lambda  (i  c)  P(  (Bst c)]))) 

whcresj  +  1=e  (§3.53.6) 

(HSMl  WITH  (PATH-TEST  : 

( LAM8DA  ( PR0JECT1 ) 

(=<  (^OCCURRENCES  CLIMAX1  PROJECT1)  1)))) 

13:105  ---  [REFINE  by  RULE389]  -  — > 

HSMl  <-  STEP-TEST  : 

(LAMBDA  (II  NOTE3 ) 

(=<  ( ^OCCURRENCES  CLIMAX1 

[APPEND  PROJECT  1  (LIST  N0TE3 ) ]  ) 


U) 
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These  rules  introduce  splits  that  can  be  propagated  upward  to  separate  a  problem.  Several  rules 
tor  partial  mulching  (§5.3 .4)  are  not  listed  here  but  have  the  same  cITcct. 


5.7.5.  Propagating  a  Split 


Once  some  component  of  a  problem  has  been  split  by  one  of  the  means  discussed  above,  the  split 
is  propagated  upward  to  split  the  problem  into  solvable  subproblcms.  [  oo's  mles  for  propagating 
such  splits  are  listed  below  with  examples  of  their  use: 

RLT.H7:  ( remove- 1- from  (set-of  x  S  PJ)  ->  (undo  (and  [in  x  S]  Px)) 

(REM0VE-1-FR0M  [SET-OF  C3  (OIFF  (CAROS)  (SET  QS ) ) 

(LEGAL  (QSO)  C3) ]) 

3:41  ---  [REDUCE  by  RULE7 ]  ---> 

(UNDO  (AND  [IN  C3  (OIFF  (CAROS)  (SET  QS))]  [LEGAL  (QSO)  C3 ] ) ) 

( REMOVE  -  1  -  FROM  [SET-OF  Cl  ( CARDS- IN-HAND  ME)  (IN-SUIT  Cl  SO)]) 

8:4  ---  [REDUCE  by  RULE7]  ---> 

(UNOO  (AND  [IN  Cl  (CAROS- IN-HAND  ME)]  [IN-SUIT  Cl  SO])) 

Rt'LFlO:  (in  c  [set-of  x  S  PJ)  ->  (and  [in  c  S]  Pc) 

(IN  ( CARDS-PLAVEDl  ME)  [SET-OF  C22  CAROS- PLAYED1 

(=  (SUIT-OF  C22)  (SUIT-LED))]) 

2:91  ---  [REMOVE-QUANT  by  RULE10]  ---> 

(AND  [IN  ( CAROS- RLAYED1  ME)  CAROS  -  PLAYED  1  ] 

[*  (SUIT-OF  (CAROS-PLAYEOl  ME))  (SUIT-LED)]) 

(IN  QS  [SET-OF  Cl  (CAROS)  (LEGAL  (QSO)  Cl)]) 

3:17  ---  [REMOVE-QUANT  by  RULE10]  ---> 

(AND  [IN  QS  (CAROS)]  [LEGAL  (QSO)  QS]) 

(IN  C3  [SET-OF  C4  (CARDS)  (HAS-POINTS  C4)]) 

6:16  ---  [REMOVE-QUANT  by  RULE10]  ---> 

(AND  [IN  C3  (CARDS)]  [HAS-POINTS  C3]) 

(IN  Cl  [SET-OF  C2  (CAROS)  (HAS  ME  C2)]) 

8:7  ---  [REMOVE-QUANT  by  RULE10]  ---> 

(ANO  [IN  Cl  (CARDS)]  [HAS  ME  Cl]) 

RLLH35:  (affect  (and  ...  P  ...» ->  (and  [affect  PJ ...) 

(UNOO  (ANO  [IN  C3  (OIFF  (CARDS)  (SET  QS))]  [LEGAL  (QSO)  C3])) 

3:42  ---  [REDUCE  by  RULE35 ]  — > 

(AND  [UNDO  (LEGAL  (QSO)  C3)]  [IN  C3  (DIFF  (CARDS)  (SET  QS))]) 
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(UNDO  (AND  [HAS  (QSO)  C3] 

[=>  (LEADING  ( QSO ) ) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 

[NEQ  (SUIT-OF  CJ)  H])] 

[=>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 

[IN-SUIT  C3  (SUIT-LED)])])) 

3:44  ---  [REDUCE  by  RULE35 ]  ---> 

(AND  [UNDO  (HAS  (QSO)  C3)] 

[=>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)] 

[NEQ  (SUIT-OF  C3 )  H])] 

[=>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)] 

[IN-SUIT  C3  (SUIT-LED)])]) 

(UNDO  (AND  [IN  Cl  ( CAROS- I N -HAND  ME)]  [IN-SUIT  Cl  SO])) 
8:5  ---  [REDUCE  by  RULE35 ]  ---> 

(AND  [UNDO  (IN  Cl  ( CARDS  -  IN -HAND  ME))]  [IN-SUIT  Cl  SO]) 

(UNDO  (AND  [IN  Cl  (CARDS)]  [HAS  ME  Cl])) 

8:3  ---  [REDUCE  by  RULE35]  ---> 

(AND  [UNDO  (HAS  ME  Cl)]  [IN-SUIT  Cl  SO]) 

(CAUSE  (AND  [HAS  PO  Cl]  [IN-SUIT  Cl  SO])) 

12:7  ---  [RCDUCE  by  RULE35]  ---> 

(AND  [CAUSE  (HAS  PO  Cl)]  [IN-SUIT  Cl  SO]) 

RULH64:  ( =  c  (the  x  S  Px»  ->  (and  [in  c  S]  P£) 

(=  (CARO-OF  ME) 

(THE  C2  (CAROS- IN-SUIT-LEO  ( CARDS- PLAYED) ) 

(FORALL  XI  (CARDS -IN-SUIT-LED  ( CARDS- PLAYED) ) 

(NOT  (HIGHER  XI  C2))))) 

5:19  ---  [by  RULE64]  ---> 

(AND  [IN  (CARD-OF  ME) 

(CAROS- IN-SUIT -LED  (CARDS- PLAYED) ) ] 

[FORALL  XI  (CARDS-IN-SUIT-LED  ( CARDS- PLAYED ) ) 

(NOT  (HIGHER  XI  (CARD-OF  ME)))]) 


RULF.U1:  (=  (the  x  S  Px)  c) ->  (and  [in  e  S]  Pc) 

(=  (THE  P2  (PLAYERS)  (=  (CARD-OF  P2)  ( WINfJING-CARD )  ) )  ME) 

6:25  ---  [REMOVE -QUANT  by  RULE  131]  ---> 

(AND  [IN  ME  (PLAYERS)]  [  =  (CARD-OF  ME)  (WI NN I NG-CARD )  ] ) 

(=  ( THE  Cl  PROJECT  1 

(FORALL  XI  PROJECT  1  (NOT  (HIGHER  XT  Cl)))) 

CLIMAX  1 ) 

13:62  ---  [REMOVE-QUANT  by  RULE131]  ---> 

(AND  [IN  CLIMAX  1  PROJECT1] 

[FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX1))]) 

RUI.H135:  (Q  x  [set-of  v  S  Py]  Rx)  ->  (Q  x  S  (and  Px  Rx)) 

(EXISTS  Cll  [SET-OF  C 12  (CAROS)  (HAS  P5  C 12 )  ] 

(IN-SUIT  Cll  (SUIT-LED))) 

2:45  ---  [by  RULE  135]  ---> 

(EXISTS  Cll  (CARDS)  (AND  [HAS  P5  Cll]  [IN-SUIT  Cll  (SUIT-LED)])) 
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RL  LH149:  (in  c  (f  S))  ->  (and  Pc  [in  c  S|))  if  f  is  defined  as  (lambda  (S)  (filter  S  P)) 

(IN  (CARD-OF  ME)  ( CAROS- IN-SU I T- LEO  ( CARDS  -  PLAYED) ) ) 

6:33  ---  [by  RULE  149]  ---> 

(AND  [IN-SUIT-LED  (CARD-OF  ME)]  [IN  (CARD-OF  ME)  ( CARDS- PLAYED )] ) 

(IN  CAROl  (CARDS- IN -SUIT-LED  ( CARDS  -  PLAYED) ) ) 

6:45  ---  [by  RULE149]  ---> 

(AND  [IN-SUIT-LED  CARD1]  [IN  CARD1  ( CARDS- PLAYED )] ) 

RULE182:  (in  e  (set  Cj ...  en)) ->  (or  [=  e  ej  ...  [=  ecj)  * 

(IN  (LOC  QS)  (SET  DECK  POT  HOLE  (HAND  ME))) 

4:32  ---  [DISTRIBUTE  by  RULE182]  ---> 

(OR  [=  (LOC  QS)  DECK] 

[*  (LOC  QS)  POT] 

[=  (LOC  QS)  HOLE]  t 

[=  (LOC  QS)  (HAND  ME)]) 

(IN  II  (SET  1)) 

13:36  ---  [DISTRIBUTE  by  RULE  182 ]  ---> 

(OR  [=  II  1]) 

RL  I.F.284:  (f ...  [g  c, ...  ej  ...)  ->  (g'  [f ...  e, ...] ...  [f ...  e„  ...])  * 

if  (lambda  (x)  (f ...  x  ...))  is  a  homomorphism, 

where  g.  g’  correspond  to  +,  +’  in  die  homomorphism  condition  flx  +  y)  =  fix)  +’  fly) 

(CHOICE -SEQ-OF  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))]) 

2:6  ---  [by  RULE234]  --->  « 

(APPEND  [CHOICE-SEQ-OF  (EACH  Pt  (PLAYERS)  (PLAY-CARD  PI))] 

[CHO ICE -SEQ-OF  (TAKE-TRICK  (TRICK-WINNER))]) 

(HAVE-POINTS  [APPEND  CARDS-PLAYED1  (LIST  C2 1 )  ]  ) 

2:102  ---  [DISTRIBUTE  by  RULE284]  ---> 

(OR  [HAVE-POINTS  CARDS -PLAYED  1  ]  [HAVE-POINTS  (LIST  C21) ]  ) 

(IN  (HAND  ME)  [UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)]) 

4:21  ---  [DISTRIBUTE  by  RULE234]  ---> 

(OR  [IN  (HAND  ME)  (HANDS  (PLAYERS))] 

[IN  (HAND  ME)  (PILES  (PLAYERS))] 

[IN  (HAND  ME)  (SET  DECK  POT  HOLE)]) 

(IN  (LOC  QS) 

[UNION  (SET  DECK  POT  HOLE  (HAND  ME))  (PILES  (PLAYERS))]) 

4:31  ---  [DISTRIBUTE  by  RULE284 ]  -— > 

(OR  [IN  (LOC  QS)  (SET  DECK  POT  HOLE  (HAND  ME))] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 

(DURING  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))] 

(TAKE  ME  QS)) 

5:7  ---  [DISTRIBUTE  by  RULE284 ]  ---> 

(OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE  ME  QS)] 

[DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE  ME  QS)]) 
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(DURING  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI) 

(TAKE-TRICK  (TRICK-WINNER))] 

(TAKE-POINTS  ME)) 

6:4  ---  [DISTRIBUTE  by  RULE284]  ---> 

(OR  [DURING  (EACH  PL  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)] 
[DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE-POINTS  ME)]) 

( ^OCCURRENCES  CLIMAX1  [APPEND  PROJECT1  (LIST  N0TE3 ) ]  ) 

13:106  ---  [DISTRIBUTE  by  RULE284]  ---> 

(+  [^OCCURRENCES  CLIMAX1  PROJECT1] 

[^OCCURRENCES  CLIMAX1  (LIST  NOTE3  )  ] ) 

( ^OCCURRENCES  (CLIMAX  CANTUS-I) 

[APPEND  CANTUS- l  (LIST  (NEXT  NOTE))]) 

14:18  ---  [DISTRIBUTE  by  RULE284]  ---> 

(*  [^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1] 

[^OCCURRENCES  (CLIMAX  CANTUS-1)  (LIST  (NEXT  NOTE;)]) 

(^OCCURRENCES  (NEXT  NOTE) 

[APPEND  CANTUS-1  (LIST  (NEXT  NOTE))]) 

14:62  ---  [DISTRIBUTE  by  RULE284]  ---> 

(+  [^OCCURRENCES  (NEXT  NOTE)  CANTUS-1] 

[^OCCURRENCES  (NEXT  NOTE)  (LIST  (NEXT  NOTE))]) 

RU!  1-.2S7:  (...  [if  P e e]  ...)->  (if  P  [... c  e'  ...]) 

(#  [IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  (SET  (NEXT  NOTE))  NIL]) 
14:22  ---  [DISTRIBUTE  by  RULE2S7]  ---> 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

[//  (SET  (NEXT  NOTE))) 

[#  NIL)) 

(*  (+  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

[IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  1  0]) 

1) 

14:25  ---  [DISTRIBUTE  by  RULE287]  ---> 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

[=  (  +  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)  1] 

[=  (+  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0)  I]) 

RL'l.F.321:  ( =  >  [P  ...J  [and  ...  [P  ...] ...])  ->  (and  [  =  >  (P  ...)  (P  ...)) ...) 

(O  [HAS  PI  C2 )  (ANO  [HAS  P5  Cll]  [IN-SUIT  C 11  (SUIT-LED)]) ) 

2:47  ---  [REDUCE  by  RULE321]  ---> 

(AND  [=>  (HAS  PI  C2 )  (HAS  P5  Cll)]  [IN-SUIT  Cll  (SUIT-LED)]) 

RULR36I:  (in  c  (filter  S  I'))  ->  (and  [in  c  SJ  Pc) 

(IN  (CARO-OF  ME)  (FILTER  ( CAROS -PLAYED )  IN-SUIT-LED)) 

5.21  ---  [ELABORATE  by  RULE361]  -— > 

(AND  [IN  (CARD-OF  ME)  ( CARDS-PLAYED ) ]  [IN-SUIT-LED  (CARD-OF  ME)]) 

(IN  QS  (FILTER  ( CAROS  -  PLAYED )  IN-SUIT-LED)) 

5:41  ---  [ELABORATE  by  RULE361]  ---> 

(ANO  [IN  QS  (CARDS-PLAYED)]  [IN-SUIT-LED  QS]) 

RULF371:  (before  A  (P  c,  ...  cn))  ->  (P  (before  A  c{) ...  (before  A  en)) 
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(BEFORE  (CURRENT  ROUND-IN-PROGRESS) 

(NOT  (OR  [IN-POT  XI]  [AT  XI  HOLE]  [HAS  ME  XI]))) 

10:15  ---  [DISTRIBUTE  by  RULE371]  ---> 

(NOT  (8EF0RE  (CURRENT  ROUND- IN-PROGRESS) 

(OR  [IN-POT  XI]  [AT  XI  HOLE]  [HAS  ME  XI]))) 

10:16  ---  [DISTRIBUTE  by  RULE371]  ---> 

(NOT  (OR  [BEFORE  (CURRENT  ROUNO-IN-PROGRESS) 

(IN-POT  XI)] 

[8EF0RE  (CURRENT  ROUND-IN-PROGRESS) 

(AT  XI  HOLE)] 

[BEFORE  (CURRENT  ROUND- I N- PROGRESS) 

(HAS  ME  XI)])) 

RULF.375:  (#  (set-ot'x  S  (not  Px)])  ->  (-  [#  S]  [#  (set-of  x  S  Px)]) 

(#  [SET-OF  XI  (CARDS- IN-SUIT  SO) 

(NOT  (BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI)))]) 
10:23  ---  [by  RULE375]  ---> 

(-  [#  (Cards- in-suit  so ) ] 

[#  (SET-OF  XI  ( CAROS  -  IN -SUIT  SO) 

(BEFORE  (CURRENT  ROUNO-IN-PROGRESS)  (HAS  ME  XI)))]) 


RULH393:  (lambda  (t)  [F...  et ...])  ->  (f ...  [lambda  (t)  cj  ...) 

(LAMBDA  (J)  [APPEND  (PREFIX  CANTUS  J)  (LIST  (NTH  CANTUS  (+  J  1)))]) 
14:13  ---  [by  RULE393 ]  ---> 

(APPEND  [LAMBDA  (J)  (PREFIX  CANTUS  J)] 

[LAMBDA  (J)  (LIST  (NTH  CANTUS  (+  J  1)))]) 

(LAMBDA  (J)  [LIST  (NOTE  (+  J  1))]) 

14: 16  ---  [by  RULE393]  ---> 

(LIST  [LAMBDA  (J)  (NOTE  (+  J  1))]) 


5.7.6.  Problem  Merging 


When  two  or  more  subproblems  share  some  regularity  that  allows  them  to  be  solved  by  a  single 

method,  it  is  sometimes  useful  to  merge  them  into  a  single  problem.  P'or  example,  in  DF.R1V14,  two 

separately  derived  constraints  arc  merged  in  terms  of  a  single  known  predicate: 

(NOT  (OR  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)])) 

14:48  ---  [COLLECT  by  RULE297]  ---> 

(NOT  ([OR  HIGHER  =]  (NEXT  NOTE)  (CLIMAX  CANTUS-1))) 

14:49  ---  [by  RULE298]  — > 

([MOT  (OR  HIGHER  =)]  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

14:50  ---  [RECOGNIZE  by  RULE299  ]  ---> 

(LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 


The  merging  transformation  at  step  14 : 48  is  performed  by 
RUL 1:297:  (B  [P  e1  c2[  [P’  cL  e,])  ->  t[B  P  P’]  ct  e2) 
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Note  that  RULE297  only  applies  to  propositions  sharing  the  same  respective  arguments  e(  and  e2. 


In  DERIV5,  two  pieces  of  advice  are  merged  into  a  single  goal: 

(UMTIL  (PLAYED!  QS) 

(AND  [ACHIEVE  (LEAD-SPADE  ME)] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  OS)))])) 
5:4  ---  [COLLECT  by  RULE360 ]  ---> 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE  (AND  [LEAD-SPADE  ME] 

[NOT  (OURING  (TRICK)  (TAKE  ME  QS))]))) 


The  second  conjunct  is  ultimately  transformed  into  die  condition  that  player  ME's  card  be  lower 

than  QS,  and  this  condition  is  used  to  modify  the  "lead  spades"  plan  to  "lead  safe  spades”: 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE  (AND  [LEADING  ME] 

[SPADE!  (CARD-OF  ME)] 

[HIGHER  QS  (CARD-OF  ME)]))) 

5:53  ---  [RECOGNIZE  by  RULE123]  ---> 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SAFE-SPADE  ME))) 


The  problem-merging  transformation  at  step  5.-4  is  performed  by 

RUI.II360:  (and  [achieve  Pt] ...  [achieve  PJ)  ->  (achieve  (and  Pj ...  Pn)) 

Note  that  the  merged  subproblcms  arc  both  of  die  form  (ACHIEVE  . .  . ). 

These  are  the  only  examples  of  problem  merging  in  die  derivations:  evidently  problem  separation 
is  a  much  more  common  strategy  in  operationalization.  Indeed,  problem  merging  is  only  applicable 
when  the  problems  to  be  merged  share  some  regularity  dial  allows  them  to  be  solved  by  a  single 
method.  In  contrast,  problem  separation  is  useful  whenever  splitting  a  problem  into  subproblcms 
permits  each  one  to  be  solved  by  the  method  most  appropriate  to  it.  It  is  unsurprising  that  the  latter 
situation  occurs  more  often;  two  or  more  randomly  generated  subproblems  are  unlikely  to  be 
solvable  by  the  same  method. 


Actually,  subproblems  need  not  be  solvable  individually  by  a  common  mcdiod  in  order  to  be 
merged:  die  only  requirement  is  that  they  fit  together  into  a  combination  that  is  solvable  as  a  unit. 
One  can  construct  cases  where  such  a  combination  is  easier  to  solve  than  the  individual  subproblcms. 
For  example,  it  may  be  difficult  to  achieve  cither  of  the  goals  C  and  ~C,  but  it  is  trivial  to  achieve 
(or  C  ~C)!  Similarly,  it  may  be  difficult  to  evaluate  e  and  -e  separately,  but  it  is  easy  to  evaluate 
( +  e  -c). 
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5.7.7.  Problem  Separation:  Summary 

The  idea  of  separadng  a  problem  into  individually  solvable  subprobiems  characterizes  case 
analysis,  condition  factoring,  partial  matching,  and  conjunctive  subgoaling.  The  key  steps  in  problem 
separation  arc  splitting  a  problem  component  and  propagating  this  split  upward  in  the  problem 
description.  Finding  the  initial  split  usually  involves  bringing  in  domain  knowledge,  typically  by 
expanding  the  definition  of  a  term  used  in  the  problem.  Propagating  a  split  upward  uses  general 
rules,  and  produces  subproblems  containing  successively  more  context.  This  process  continues  until 
each  subproblem  can  be  solved  by  available  methods.  Sometimes  it  is  not  necessary  to  solve  all  the 
subprobiems.  for  example  when  achieving  a  disjunction  or  disproving  a  conjunction.  Problem 
separation  is  a  general  technique  for  applying  special-purpose  methods .  since  it  allows  each  subproblem 
to  be  solved  using  the  methods  appropriate  to  it.  independently  of  how  the  other  subprobiems  are 
solved.  This  flexibility  appears  to  explain  the  contrasting  rarity  of  problem  merging,  which  only  works 
when  the  merged  problems  arc  sufficiently  similar  to  be  solved  by  a  common  method. 


5.8.  Translation 

A  useful  strategy  for  making  a  problem  easier  to  solve  is 
Translate  the  problem  into  the  language  of  known  methods. 

While  many  rales  transform  one  expression  into  another  that  contains  different  symbols,  this 
section  focuses  specifically  on  rules  whose  primary  purpose  is  translation  rather  some  other  process 
( e.g evaluation,  partial  matching,  problem  separation).  Translation  is  one  kind  of  change  of 
representation |Korf  30).  A  translation  rale  has  the  general  form  (f  Cj  ...  cn)  •>  (g  e^  ...  ck’)  and 
introduces  a  change  of  vocabulary,  as  opposed  to  a  change  of  syntax  f§  5. 1 0).  ft  can  be  classified 
according  to  which  of  the  concepts  f  and  g  is  more  specific;  f  is  considered  more  specific  than  g  if 
every  expression  ((...)  is  expressible  as  (g  ...),  but  not  vice  versa.  This  criterion  splits  the  class  of 
translation  rales  into  three  kinds; 

1.  Elaboration:  f  is  more  specific  dian  g.  Fxpanding  the  definition  of  f  is  elaboration. 

2.  Recognition:  g  is  more  specific  than  f.  Substituting  g  for  its  definition  is  recognition. 

3.  Lateral  rephrasing:  neither  f  nor  g  is  more  specific.  Translation  other  than  elaboration  or 
recognition  is  lateral  rephrasing. 

The  rest  of  this  section  is  organized  as  follows.  (.§5.8.1)  illustrates  the  concept  of  translation  by 
means  of  an  example.  The  succeeding  three  sections  present  f'OO's  rules  for  elaboration  (§5.8.2), 
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recognition  (§5.8.3),  and  lateral  rephrasing  (§5.8.4).  Recognition  and  elaboration  correspond  to 
Darlington  and  Burstall's  “folding”  and  “unfolding"  operations  (Darlington  ”6].  (§5.8.5) 

characterizes  the  three  kinds  of  translation  rules  as  operators  moving  in  different  directions  in  the 
operationalization  problem  space. 

5.8.1.  An  Example  of  Translation  from  Numerical  to  Set  Concepts 

A  nice  example  of  translation  occurs  in  DERIV14  in  the  course  of  the  reduction 
(=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  0)  ->  NIL 

First  a  sub-expression  is  elaborated  by  plugging  in  the  definition  of  ^OCCURRENCES: 

(^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

14:29  ---  [ELABORATE  by  RULE  124]  ---> 

(U  [SET-OF  X2  CANTUS-1  (=  X2  (CLIMAX  CANTUS-1))]) 

This  produces  an  expression  of  the  form  (=  (#  (set-of  x  S  P  ])  0),  which  can  be  recognized  as 
(empty  [set-of  x  S  Px().  Such  a  transformation  qualifies  as  recognition  since  any  expression  of  the 
form  (empty  S)  can  be  expressed  as  (  =  (#  S)  0).  but  not  every  expression  ( =  e  e‘)  can  be  expressed 
in  the  form  (empty ...)  --  at  least  in  a  “natural"  way.  The  latter  qualification  reflects  die  difficulty  of 
precisely  defining  relative  specificity  so  as  to  rule  out  perverse  equivalents  for  (=  c  e')  such  as 
(empty  (set-of  x  {e}  (*  x  c')[).  Perhaps  f  should  be  called  more  specific  than  g  if  (f  ...)  can  be 
expressed  in  terms  of  g  more  easily  than  vice  versa  -  whatever  “more  easily"  means. 

The  next  step  in  the  derivation  reformulates  an  equality  as  a  negated  quantification: 

(=  (ft  [SET-OF  X2  CANTUS-1  (=  X2  (CLIMAX  CANTUS-1))])  0) 

14;30  ---  [RECOGNIZE  by  RULE291]  ---> 

(NOT  (EXISTS  X2  CANTUS-1  ( =  X2  (CLIMAX  CANTUS-1)))) 

This  step  combines  recognition  and  lateral  rephrasing: 

(=  {»  [SET-OF  X2  CANTUS-1  (=  X2  (CLIMAX  CANTUS-1))])  0) 

—  [recognize]  — > 

(EMPTY  [SET-OF  X2  CANTUS-1  (=  X2  (CLIMAX  CANTUS-1))]) 

—  [laterally  rephrase]  — > 

(NOT  (EXISTS  X2  CANTUS-1  (  =  X2  (CLIMAX  CANTUS-1)))) 

The  rule  for  this  composite  transformation  is 

RUI.E291:  (  =  (#  [set-of  x  S  PJ)  0)  ->  (not  (exists  x  S  P^)) 

An  equality  quantified  over  a  set  can  be  recognized  in  terms  of  membership  in  that  set: 


258 


§5.  Analysis  Methods 


1 


(EXISTS  X2  CANTUS- 1  (=  X2  (CLIMAX  CANTUS-1))) 
14:31  ---  [RECOGNIZE  by  RULE292]  ---> 

(IN  (CLIMAX  CANTUS-1)  CANTUS-1) 


This  transformation  is  expressed  by 

RULE292:  (exists  x  S  ( =  x  e))  ->  (in  c  S) 


t 


Now  the  sub-expression  ( CLIMAX  CANTUS-1 )  is  elaborated  by  plugging  in  its  definition: 
(CLIMAX  CANTUS-1) 

14:32  ---  [ELABORATE  by  RULE  124]  ---> 

(HIGHEST  CANTUS-1) 


The  latter  expression  fits  the  language  of  an  opportunistic  evaluation  method  (§5.2.3): 
RULE-293:  (in(one-ofS)S)->T 


This  method  helps  reduce  the  overall  expression  to  NIL: 

(NOT  (IN  (HIGHEST  CANTUS-1)  CANTUS-1)) 
14:33  ---  [SIMPLIFY  by  RULE293]  ---> 
(NOT  T) 

14:34  ---  [COMPUTE  by  RULE236]  ---> 

NIL 


Most  of  this  example  consisted  of  translating  the  initial  expression  from  the  language  of  numerical 
concepts,  like  tf  and  o,  into  the  language  of  set-related  concepts.  like  IN  and  HIGHEST.  Once  this 
translation  was  accomplished,  by  a  combination  of  elaboration,  recognition,  and  lateral  rephrasing, 
the  desired  proof  was  obtained  immediately  by  applying  a  method  expressed  in  die  language  of  sets. 


Note  that  using  translation  to  solve  this  problem  in  an  automatic  (rather  titan  user-guided)  mode 
would  require  capabilities  lacking  in  FOO  (§8.1.1): 

1.  A  way  to  make  the  initial  decision  to  restate  the  problem  in  terms  of  sets.  What  clue  in  the 
initial  problem  suggests  this  as  a  plausible  goal?  One  possibility  is  to  establish  a  permanent  (/.?., 
problem-independent)  goal  of  applying  powerful  problem-solving  and  problem-reducing 
methods,  e.g.,  opportunistic  evaluation  rules  like  RULF.293  in  the  example.  The  desire  to  apply 
RUl.lf.293  would  motivate  the  attempt  to  translate  the  initial  problem  into  die  language  of  sets. 
A  potential  difficulty  of  this  approach  is  an  excessive  number  of  such  goals.  Avoiding  diis 
might  require  an  efficient  means  to  eliminate  infeasible  methods,  e.g..  by  some  kind  of 
intersection  search  between  the  concepts  used  in  the  problem  and  the  concepts  used  in  the 
method. 

2.  A  way  to  guide  the  translation  process  toward  a  chosen  goal  without  wasting  too  many  moves. 
One  approach  is  to  use  means-end  analysis,  with  rules  as  operators  (§?). 
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The  preceding  example  is  almost  pure  translation,  and  therefore  ideal  for  illustrative  purposes. 
More  typically,  translation  .o  interleaved  with  other  transformations,  as  in  DER1V4,  where  the 
problem  of  deciding  whether  the  Queen  of  spades  is  out  is  translated  into  the  language  of  the  pigeon¬ 
hole  principle.  The  translation  begins  by  successive  elaboration: 

(QS-OUT) 

4:1  ---  [ELABORATE  by  RULE  124]  — > 

(OUT  QS) 

4:2  ---  [ELABORATE  by  RULE  124]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  QS)) 

(HAS  PI  QS) 

4:3  ---  [ELABORATE  by  RULE124]  ---> 

(AT  QS  (HAND  PI)) 

4:4  ---  [ELABORATE  by  RULE124]  ---> 

(=  (LOC  QS)  (HAND  PI)) 


This  is  followed  by  a  change  of  variable  using 

RULEL61:  (Q  x  S  [P  ...  (f  x) ...])  ->  (Q  y  (project  fS)  [P  ...  y  ...]) 


The  effect  is  to  restructure  the  quantification  (§5.10): 

(EXISTS  PI  (OPPONENTS  ME)  [  =  (LOC  QS)  (HAND  PI)]) 

4:5  ---  [COLLECT  by  RULE  161 ]  ---> 

(EXISTS  Y1  (PROJECT  HAND  (OPPONENTS  ME))  [=  (LOC  QS)  Yl]) 


The  equality,  quantified  over  hands  instead  of  players,  is  recognized  in  terms  of  set  membership: 

4:6  ---  [RECOGNIZE  by  RULE162]  — -> 

(IN  (LOC  QS)  (PROJECT  HAND  (OPPONENTS  ME))) 


The  recognition  is  performed  by 

RUI.F.162:  (exists  x  S  ( =  e  x))  ■>  (in  e  S) 


The  set  membership  matches  the  problem  statement  for  the  pigeon-hole  principle  (§2.2): 

(IN  (LOC  QS)  (PROJECT  HAND  (OPPONENTS  ME))) 

4:7  ---  [by  RULE169]  ---> 

(NOT  (IN  (LOC  QS)  (DIFF  (RANGE  LOC) 

(PROJECT  HAND  (OPPONENTS  ME))))) 


A  restructuring  rule  is  used  in  this  example  to  help  the  translation  go  through.  In  general, 
translation  is  interspersed  with  evaluation,  simplification,  reduction,  and  other  analysis  methods. 
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5.8.2.  Elaboration 

Elaboration  unpacks  implicit  details  to  make  them  available  for  analysis,  moving  downward  from 
compact  descriptions  based  on  highly  specific  concepts  to  extensive  descriptions  based  on  more 
primitive  terms  at  a  lower  level  of  detail.  Elaborating  a  specialized  concept  is  useful  when  available 
methods  do  not  apply  to  it  directly,  but  do  apply  to  more  general  concepts  used  in  its  expanded  form. 
In  this  sense,  elaboration  provides  a  way  to  exploit  general  methods. 

The  most  common  kind  of  elaboration  consists  of  plugging  in  the  definition  of  a  concept  using 

RU1.EL24:  (fe; ...  en)  ->  e.  where  f  is  defined  as  (lambda  (Xj ...  xn)  <body>) 
and  e  is  the  result  of  substituting  e1 ...  en  for  Xj ...  xn  throughout  <body> 

For  example: 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

6:2  ---  [ELABORATE  by  RULE  124]  ---> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 


Here  f=  AVOID, defined  as  (LAM80A  (E  S)  (ACHIEVE  (NOT  (DURING  S  E)))). 


RULF.124  is  by  far  the  most  frequently  used  of  all  the  rules  in  TOO;  it  accounts  for  more  daan  100 
steps  in  the  derivations. 


TOO  also  has  some  special-case  elaboration  rules,  listed  below  with  examples  of  their  use. 
RUI.E4:  (subset  S1  SO  ->  (empty  (diff S1  S2)) 

(SUBSET  (LEGALCARDS  (QSO ) )  (SET  QS)) 

3:37  ---  [by  RULE4  ]  ---> 

(EMPTY  (DIFF  (LEGALCARDS  (QSO))  (SET  QS))) 

RULF.14:  (in  e  (project  fS))  ->  (exists  x  S  (  =  e  (f  x))) 

(IN  (LOC  QS)  (PROJECT  PILE  (PLAYERS))) 

4:45  ---  [by  RULE  14]  ---> 

(EXISTS  P3  (PLAYERS)  (=  (LOC  QS)  (PILE  P3))) 


RLI.H14  collapses  an  elaborate-and-transfer  (§5.10.2)  sequence: 

(in  c  (project  f  S))  -> 

(exists  y  (project  f  S)  ( =  e  y)>  -> 

(exists  x  S  (  =  e(f.x))) 

RULH15:  (partition  St ...  Sn)  ->  (union  S; ...  Sn).  recording  assumption  (disjoint  S; ...  Sn) 


§5.8.2.  Elaboration 


261 


(PARTITION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

4:10  ---  [GENERALIZE  by  RULE  15]  ---> 

(UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

ASSUME  (OISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

RULE381:  (indices-of  S)  ->  (lb'.ub  1  (#  S)),  where  S  is  a  sequence  indexed  by  integer 

(IMOICES-OF  PROJECT  1) 

13:32  ---  [ELABORATE  by  RULE381]  ---> 

(LB-.U8  1  (#  PROJECT  1 ) ) 


5.8.3.  Recognizing  Known  Concepts 

Recognition  moves  upward  from  primitive  concepts  to  specialized  ones  that  may  yield  to  special- 
case  methods;  thus  recognition  exploits  special  cases.  This  was  illustrated  in  an  earlier  example: 
although  roo  has  no  direct  evaluation  ailes  for  conditions  of  the  form  ( =  ...)  k)  for  arbitrary  k,  a 

condition  of  the  form  ( =  ( ft  ...)  0)  was  evaluated  by  using  knowledge  about  set  membership. 


The  most  common  kind  of  recognition  consists  of  substituting  a  concept  for  its  definition  using 

RULE123:  e  ->  (f  ct ...  en)  if  f  is  defined  as  (lambda  (x j  ...  xn)<body>) 
and  e  is  the  result  of  substituting  e( ...  en  for  xA  ...  xn  throughout  <body> 


This  rule  was  the  second  most  frequently  used  (over  40  times).  It  is  illustrated  in  DER1V8: 

(MOVE  Cl  (HAND  ME)  LOCI) 

8:11  ---  [RECOGNIZE  by  RULE  123 ,  binding  LOCI  <-  POT]  ---> 

(PLAY  ME  Cl) 


A  variant  form  was  used  in  DERIV14  to  recognize  lambda  expressions  as  known  functions: 

RUEE267:  (lambda  (xt ...  xn)  c)  ->  f  if  f  is  defined  as  (lambda  (Xj‘ ...  xn')  <body>) 
and  c  is  the  result  of  substituting  x^ ...  xn  for  x^  ...  x  ’  throughout  <body> 

(LAMBDA  (Jl)  (PREFIX  CANTUS  Jl)) 

14:3  ---  [RECOGNTZE  by  RULE267]  -— > 

CANTUS- 1 


FOO's  other  recognition  rules  arc  listed  below  with  examples  of  their  use. 


RLLEI62:  (exists  x  S  ( =  ex))  ->  (in  e  S) 
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(EXISTS  Y 1  (PROJECT  HAND  (OPPONENTS  ME))  (=  (LOC  QS)  Y1 ) ) 
4:6  ---  [REMOVE-QUANT  by  RULE  162 ]  ---> 

(IN  (LOC  QS)  (PROJECT  HANO  (OPPONENTS  ME))) 

(EXISTS  PI  (OPPONENTS  ME)  ( =  PO  PI)) 

9:36  ---  [REMOVE-QUANT  by  RULE  162]  ---> 

(IN  PO  (OPPONENTS  ME)) 

RUI.K291:  (  =  ( ft  [set-of  x  S  PJ)  0)  ->  (not  (exists  x  S  Px)) 

(=  {#  (SET-OF  X5  PROJECT  1  (=  X5  CLIMAX1)))  0) 

13:113  ---  [RECOGNIZE  by  RULE291]  ---> 

(NOT  (EXISTS  X5  PROJECT1  (=  X5  CLIMAX  1 ) )  ) 

(=  (#  (SET-OF  X2  CANTUS- 1  (=  X2  (CLIMAX  CANTUS-1))))  0) 
14:30  ---  [RECOGNIZE  by  RULE291]  ---> 

(NOT  (EXISTS  X2  CANTUS-1  (  =  X2  (CLIMAX  CANTUS-1)))) 


RULF.291  collapses  a  recognizc-and-rephrasc  sequence: 

(=  (ft  [set-of  xSPx))0)  -> 

(empty  [set-of  x  S  Px})  -> 

(not  (exists  x  S  Px)) 

RULF292:  (exists  x  S  ( =  x  e))  ->  (in  e  S)  --  symmetric  form  ofRULl\l62 

(EXISTS  X2  PROJECT  1  (=  X2  CLIMAX1)) 

13:86  ---  [RECOGNIZE  by  RULE292]  ---> 

(IN  CLIMAX1  PROJECT  1 ) 

(EXISTS  X2  CANTUS-1  (=  X2  (CLIMAX  CANTUS-1))) 

14:31  ---  [RECOGNIZE  by  RULE292]  ---> 

(IN  (CLIMAX  CANTUS-1)  CANTUS-1) 

(EXISTS  X5  CANTUS-1  (=  X5  (NEXT  NOTE))) 

14:72  ---  [RECOGNIZE  by  RULE292]  — > 

(IN  (NEXT  NOTE)  CANTUS-1) 

RUI.H294:  (ifC  nil  P)  ->  (and  P  [not  C]) 


(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

NIL 

(=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)) 
14:36  ---  [RECOGNIZE  by  RULE294]  ---> 

(ANO  [-  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 
[NOT  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]) 

RUL.H352:  (=  P  nil)  ->  (not  P) 


(*  (LEADING  ( QSO) )  NIL) 

3:89  ---  [SIMPLIFY  by  RULE352]  ---> 
(NOT  (LEADING  (QSO))) 


RLLE358:  (cause  (at  obj  loc))  ->  (move  obj  !oc'  loc).  asserting  variable  ! ac  *  loc 
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(CAUSE  (AT  QS  (PILE  P3 ) ) ) 

4:51  ---  [RECOGNIZE  by  RULE358 ]  -*-> 

(MOVE  QS  LOCI  (PILE  P3)) 

(CAUSE  (AT  XI  (HAND  PI))) 

10:8  ---  [RECOGNIZE  by  RULE258]  ---> 

(MOVE  XI  LOCI  (HAND  PI)) 

RL  I.H367:  (not  (P  c))  ->  (P’  e).  where  P'  is  the  opposite  of  P 

(NOT  (LOW  (CARD-OF  ME))) 

7:8  ---  [by  RULE367]  ---> 

(HIGH  (CARD-OF  ME)) 


RULF363:  (undo  (at  obj  loc))  ->  (move  obj  loc  loc'),  asserting  variable  lee’  *  loc 

(UNDO  (AT  Cl  (HAMO  ME))) 

8:10  ---  [RECOGNIZE  by  RULE368]  ---> 

(MOVE  Cl  (hAND  ME)  LOCI) 


RULE377:  (undo  (not  P))  ->  (cause  P) 

(UNDO  (NOT  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO)))) 
12:3  ---  [RECOGNIZE  by  RULE377 ]  ---> 

(CAUSE  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))) 


RU.K382:  (diff  [lb:ub  lx  u]  [lb:ub  1,  u])  ->  (lb:ub  \L  (- 1, 1)) 

(DIFF  [L8.UB  1  (t)  PROJECT  1 ) ]  [LB:UG  2  {#  PROJECT1)]) 
13:33  ---  [REDUCE  by  RULE382 ]  ---> 

(L8:UB  1  (-  2  1)) 

RUEH387:  (>=  (if  [set-ofx  S  PJ)  1) ->  (exists  x  S  Px> 

(>=  (#  (SET-OF  X2  PROJECT  1  (=  X2  CLIMAX1)))  1) 

13:85  ---  [RECOGNIZE  by  RULE337]  ---> 

(EXISTS  X2  PROJECT  1  (=  X2  CLIMAX1)) 


RULE3S7  is  closely  related  to  RUI  H291: 

<>  =  {it  [set-ofx  Sl\l)  1) 

->  ( not  (<  ( ft  (set-of  x  S  P  ])  1))  --  "greater  or  equal"  =  "nut  less  than  " 

->  (not  ( =<  (ft  [set-of  x  S  PJ)  0))  -  "less  than  l"  =  "0  or  less"  for  integers 
->  (not  ( =  ( ft  [set-of  x  S  Pj)  0))  -  "non-positive"  -  "0" for  non- negative  numbers 
->  (not  (empty  [set-of  x  S  P  ]))  --  recognise  "cardinality  0" as  "empty" 

->  (exists  x  S  P  )  -  recognize  "non-empty  intension" as  existential  predicate 

RUI. 1-391:  (if  C  P T)  ->  (or  [not  C]  P) 

(IF  (=  CLIMAXI  NOTE3) 

(*<  (^OCCURRENCES  CLIMAXI  PROJECT  2 )  0) 

T) 

13:109  ---  [RECOGNIZE  by  RULE331]  ---> 

(OR  [NOT  (=  CLIMAXI  NOTE3 ) ] 

[=<  (^OCCURRENCES  CLIMAXI  PROJECTl)  0]) 
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RULE392:  ( =  <  o  0)  ->  (=  e  0)  it'  c  is  non-negative  (eg-,  the  size  of  a  set) 

(=<  ( ^OCCURRENCES  CLIMAX!  PR0JECT1)  0) 

13:111  ---  [RECOGNIZE  by  RULE392]  ---> 

(=  (^OCCURRENCES  CLIMAX!  PROJECT!)  0) 


5.8.4.  Rephrasing  in  Different  Terms  at  the  Same  Level  of  Detail 

Lateral  rephrasing  translates  a  problem  into  different  terminology  so  as  to  allow  application  of 
methods  expressed  in  it,  moving  sideways  at  more  or  less  die  same  level  of  conceptual  detail.  It  covers 
translation  other  than  elaboration  and  recognition,  and  provides  a  way  to  exploit  methods  expressed 
in  different  terms  than  the  problem  at  hand. 


POO's  lateral  rephrasing  rules  are  listed  below  with  examples  of  their  use. 

RL  L.HI53:  (R  ex  e2)  ->  (RTe2  c^,  where  RT  is  die  transpose  of  die  binary  relation  R 

(HIGHER  XI  (CARD-OF  ME)) 

7:5  ---  [by  RULE153]  ---> 

(LOWER  (CARD-OF  ME)  XI) 

(HIGHER  (FIND-ELT  ( CARD- I N-SUI T- LED  ( CARDS- PLAYED )) )  (CARD-OF  ME)) 

5:42  ---  [by  RULE  153 ]  ---> 

(LOWER  (CARD-OF  ME)  (FIND-ELT  { CARD- I M-SUIT-LED  ( CARDS- PLAYED) )) ) 

* 

(HIGHER  DK  (CARD-OF  ME)) 

6:62  ---  [by  RULE  153 ]  -  — > 

(LOWER  (CARD-OF  ME)  DK) 

(>=  1  (^OCCURRENCES  CLIMAX1  PR0JECT1)) 

13:37  ---  [by  RULE  153 ]  ---> 

(=<  (^OCCURRENCES  CLIMAX1  PR0JECT1)  1)  * 

RLT.H159:  (not  (exists  x  S  Px))  ->  (empty  (set-of  x  S  P^)) 

(NOT  (EXISTS  Cl  (CARDS-IN-HANO  ME)  (IN-SUIT  Cl  SO))) 

8:2  ---  [by  RULE  159]  ---> 

(EMPTY  (SET-OF  Cl  (CARD- IN-HAND  ME)  (IN-SUIT  Cl  SO)))  f 

RLLF.164:  (diff  SL  (diffS2  S-j])  ->  (union  [diff  Sj  S-J  (intersect  S1  S3]) 


s 
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(DIFF  (UNION  (HANDS  ( PLAYERS)  ) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)) 

[DIFF  (HANDS  (PLAYERS))  (SET  (HAND  ME))]) 
4:15  ---  [DISTRIBUTE  by  RULE  164]  ---> 

(UNION  [DIFF  (UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

(HANDS  (PLAYERS))) 

[INTERSECT  (UNION  (HANDS  (PLAYERS)) 
(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)] 
(SET  (HAND  ME)})) 


RU1.H164  expresses  a  set  identity  derivable  bv  expanding  the  definition  of  set  difference,  applying 
De.Morgan's  Law.  and  recognizing  the  definition  of  set  difference.  The  following  proof  uses  the 
notation  AB  for  intersection.  A'  for  complement.  A-B  for  difference,  and  AUB  for  union. 

A-(B-C) 

->  A(BC)'  by  expanding  definition  of  set  difference  X  •  V  as  XY’ 

->  AUV  U  C")  bv  De.Morgan's  Law  (XY)’  =  X’  U  Y’ 

->  A(  B'  U  C)  bv  simplify  ing  double  complement  X"  =  X 
->  AB'  U  AC  by  distributive  lavs  X(Y  U  Z)  =  XY  U  XZ 
->  (A  -  B)  U  AC  by  recognizing  XY'  as  definition  of  X  -  Y 


RILE21S:  ( =  S  (filter  S  P))  ->  ( =  >  (in  x  S)  P^).  where  x  is  implicitly  universally  quantified 

(=  ( CARDS- IN-HAND  PQ)  (FILTER  ( CARDS- IN-HAND  PO)  OUT)) 

9:28  ---  [by  RULE 2 18 ]  ---> 

(=>  (IN  X2  (CARDS- IM-HANO  PO))  (CUT  XZ)) 


5.8.5.  Translation:  Summary 

Translation  moves  a  problem  through  a  space  of  equivalent  expressions.  Its  purpose  is  to  move  the 
problem  into  a  region  where  known  methods  for  operationalization  and  analysis  can  be  applied. 
Each  kind  of  translation  corresponds  to  a  different  direction  in  this  space: 

1.  Flaboration  moves  downward  lo  a  lower  level  of  detail,  often  by  expanding  definitions. 

2.  Recognition  moves  upward  from  primitive  concepts  to  more  domain-specific  ones. 

3.  l  ateral  rephrasing  moves  sideways  at  more  or  less  die  same  level  of  detail. 

lints  translation  is  a  change  of  problem  representation  based  on  change  of  vocabulary.  In  practice, 
translation  rules  arc  used  together  with  other  rules  to  map  problems  to  available  methods. 
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5.9.  Problem  Reduction 

A  common  problem-solving  strategy  is 
Reduce  the  problem  to  an  easier  one. 

Problem  reduction  differs  from  simplification  by  its  heuristic  nature.  A  simplified  problem  is 
always  semantically  equivalent  to  the  original  one  and  at  least  as  easy  to  solve;  thus  simplification  is 
both  logically  valid  and  heuristically  useful.  The  rules  in  this  section  do  not  enjoy  these  properties; 
they  may  not  be  guaranteed  to  preserve  equivalence,  or  to  be  useful  even  if  applicable. 

The  term  "problem  reduction"  is  often  used  in  a  sense  that  encompasses  the  idea  of  problem 
separation  discussed  earlier  (§5.7).  In  contrast,  the  term  is  used  here  to  refer  to  the  transformation  of 
a  problem  into  one  caiser  problem,  rather  than  into  a  collection  of  subproblems.  Thus  a  problem 
reduction  rule  has  the  general  form  e  ->  e’  if  C.  where  e'  is  easier  than  e  in  some  sense.  Such  rules  can 
be  classified  according  to  the  difficulty  of  testing  the  condition  C. 

One  category  contains  rules  where  die  condition  C  is  tested  by  analysis,  Le..  by  recursively 
invoking  the  whole  collection  of  analysis  rules  to  evaluate  C.  These  rules,  discussed  in  (§5.9,1),  check 
for  special  cases,  such  as  necessary  (§5.9. 1.2)  or  sufficient  (§5.9. 1.1)  conditions  on  e. 

Another  category,  treated  in  (§5.9.2),  contains  reduction  rules  where  C  can  be  tested  without 
analysis.  Some  of  these  rules  preserve  semantic  equivalence,  but  unlike  simplification  rules,  should 
not  always  be  applied  (§5.9.2. 1).  Others  violate  semantic  invariance  by  producing  a 
sufficient  (§5.9.2.2)  or  necessary  (§5. 9. 2.3)  condition  c"  on  the  original  expression  e,  or  some  other 
non-equivalent  expression  (§5.9.2.4).  (§5.9. 2.2.1)  discusses  reduction  to  a  sufficient  condition  in 
terms  of  relevant  ini  plication. 

The  above  distinctions  between  different  classes  of  reduction  rules  are  blurred  in  practice  (§5.9.3). 
For  example,  a  rule  condition  can  be  treated  as  an  untested  assumption  (§5.9. 3.1)  or  reduced  to  a 
simpler  unproved  condition  (§5.9.3.2),  which  can  be  treated  as  a  subgoal  or  as  a  restriction  on  the 
applicability  of  die  eventual  solution.  Relationships  between  different  kinds  of  reduction  rules  arc 
summarized  in  (§5.9.4). 


§5.9.1.  Reduction  Based  on  Analysis:  Checking  for  a  Special  Case 


267 


5.9.1.  Reduction  Based  on  Analysis:  Checking  for  a  Special  Case 

Some  reduction  rules  are  of  the  form  e  ->  e'  if  C,  where  the  transfonnation  e  ->  e’  is  vu/Yt/fprescrvcs 
semantic  equivalence)  in  die  special  case  described  by  C,  and  evaluating  C  requires  analysis.  An 
example  of  a  reduction  rule  diat  checks  for  a  special  case  is 

RULE362:  (Q  x  S  [...  (in  x  S') ...])  ->  (Q  x  S  {...])  if  (subsets  S’) 

RULE362  is  used  in  DER1V6  to  simplify  die  expression 

(EXISTS  C3  (CARDS-PLAYED)  (AND  [IN  C3  (CARDS)]  [HAS-POINTS  C3])) 

Verifying  the  rule  condition  requires  analysis: 

(SUBSET  (CARDS-PLAYED)  (CAROS)) 

6:18  ---  [FACT  by  RULE363]  ---> 

T 


Reducing  the  expression  allows  it  to  be  simplified  and  recognized  as  a  familiar  concept: 

(EXISTS  C3  (CAROS-PIAYED)  (AND  [HAS-POINTS  C3])) 

6:20  ---  [SIMPLIFY  by  RULE  1 78]  ---> 

(EXISTS  C3  (CARDS-PLAYED)  (HAS-POINTS  C3)) 

6:21  — «  [RECOGNIZE  by  RULE  123]  ---> 

(HAVE-POINTS  (CARDS-PLAYED)) 

6:22  ---  [RECOGNIZE  by  RULE  123]  ---> 

(TRICK-HAS-POINTS) 


Another  special  case  reduction  rule  is 

RUI.F.19:  (diff[join  ...  S  ...  $J  S)  ■>  (join  ...  S|(l  if  (disjoint  S(  ...  S  ...  Sn) 


RU1.K19  is  used  in  DUR1V4  to  make  the  reduction 

(DIFF  [UNION  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)] 

[HANOS  (PLAYERS)]) 

4:16-18  ---  [REDUCE  by  RULE  13 ,  analysis]  *--> 
(UNION  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 


RU  l.Hld's  condition  is  verified  by  analysis  to  check  the  validity  of  applying  it  to  the  expression: 

(DISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

4:17  ---  [EVAL  by  RULE346]  ---> 

T 
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Other  special  ease  reduction  rules  are  listed  below  with  examples  of  their  use: 


RU1.E300:  (next  (f  S))  ->  (f  (change  S))  if  (R  (f  (change  S)]  [f  SI), 

assuming  (next  S)  includes  S,  where  R  is  an  ordering,  (f  S)  is  die  R-extremum  of  S,  and 
(change  S)  =  (diff  (next  S)  S) 

(NEXT  (HIGHEST  CANTUS-1)) 

14:55-57  ---  [REDUCE  by  RULE300 ,  analysis]  ---> 

(HIGHEST  (CHANGE  CANTUS-1)) 

since  (HIGHER  (HIGHEST  (CHANGE  CANTUS-1))  (HIGHEST  CANTUS-1)) 
assuming  (SUBSET  CANTUS-1  (NEXT  CANTUS-1)) 

RULE324:  (=  [f  SJ  [f  S^])  ->  (in  [f  SJ  S,)  if  (subset  S2  Sj),  where  (f  S)  is  an  extremum  of  S 

(=  [HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS))] 

[HIGHEST- IN-SUIT -LED  CARDS -PLAYED  1 ] ) 

2:63-64  -  [by  RULE324,  assumption]  - > 

(IN  [HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS))] 

CARDS-PLAYED1] ) ) 

assuming  (SUBSET  CAR0S-PLAYE01  (PROJECT  CARD-OF  (PLAYERS))) 

RULE325:  ( =  [St  i]  [S?  i])  ->  (in  i  (indices-of  S,))  if  (subset  S,  S{),  where  (S  i)  =  (nth  S  i) 

(=  [(PROJECT  CARD-OF  (PLAYERS))  ME]  [CAR0S-PLAYED1  ME]) 

2:66-67  ---  [by  RULE325,  ASSUME  by  RULE32]  ---> 

(IN  ME  (INDICES-OF  CARDS-PLAYED1 ) ) 

assuming  (SUBSET  CARDS-PLAYED1  (PROJECT  CARD-OF  (PLAYERS))) 


5.9.1. 1  Checking  a  Sufficient  Condition 


An  important  special  case  of  checking  for  a  special  case  is  a  rule  tliai  checks  for  a  sufficient 
condition,  i.e.,  lias  the  form  c  ->  T  if  C.  where  C  is  a  sufficient  condition  for  c.  One  such  rule  is 

RUI.H336:  (  =  >  [P  Sr|  [P  S;])  ->  T  if  (subset  St  S2),  where  P  =  (lambda  (S)  (exists  x  S  Rx)) 


R UJ-L-I336  is  used  in  DP.RIV2  to  evaluate 

(=>  [HAVE-POINTS  (PREFIX  CARDS-PLAYED1  ANY)] 
[HAVE-POINTS  CARDS-PLAYED1]) 

2:97-99  ---  [REDUCE  by  RULE336 ,  analysis]  — > 
T 


Here  any  is  lazy  notation  for  a  universally  quantified  (non-negative  integer)  variable.  The  analysis 

in  this  example  consists  of  verifying  that  the  special  case  holds: 

(SUBSET  (PREFIX  CARDS-PLAYED1  ANY)  CAROS  -  PLAYED  1 ) 

2:98  ---  [EVAL  by  RULE337 ]  — > 

T 


Another  rule  that  checks  for  a  sufficient  condition  is 


§5.9.1.1.  Checking  a  Sufficient  Condition 
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RULE383:  (  =  >  [R  et  c]  [R  e-,  e])  ->  T  if  (R  e,  Cj).  where  R  is  transitive 


The  validity  of  RULE383  follows  from  the  definition  of  transitivity: 
R  is  transitive  if  (R  e2  Cj)  and  (R  e^  e)  implies  (R  e2  e) 


Whenever  the  rule  condition  (R  e,  Cj>  is  true,  (R  Cj  c)  implies  (R  e2  c).  Thus  die  rule  condition 

(R  e,  Cj)  is  a  sufficient  condition  for  ( =  >  [R  e(  e]  [R  e2  c]).  However,  it  is  not  a  necessary  condition. 

For  example,  if  (R  x  e)  is  false  for  all  x.  then  (  =  >  [R  Cj  e]  [R  e.  e])  is  vacuously  true  (since  false 

implies  anything),  even  if  the  condition  (R  e,  is  false.  (Consider,  say,  e  =  Ace,  ej  =  King,  e2  = 

Queen,  and  R  =  HIGHER.)  RULF383  is  used  twice  in  DERIV'D: 

(=>  [  =  <  (MELODIC-RANGE  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH)))) 

(MAJOR  10)] 

[  =  <  (MELODIC-RANGE  PR0JECT1)  (MAJOR  10)]) 

13:45-48  ---  [REOUCE  by  RULE 383 ,  analysis]  ---> 

T 

since  (=<  (MELOOIC-RANGE  PR0JECT1) 

(MELOOIC-RANGE  (PROJECT  NOTE  (L8:UB  1  (CANTUS-LENGTH))))) 

(=>  [  =  <  (^OCCURRENCES  CLIMAX1 

(PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH)))) 

1) 

[=<  (^OCCURRENCES  CLIMAX1  PROJECT1)  1)) 

13:93-100  ---  [REDUCE  by  RULE383 ,  analysis]  ---> 

T 

since  (=<  (^OCCURRENCES  CLIMAX1  PR0JECT1) 

(^OCCURRENCES  CLIMAX1 

(PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))))) 


5.9.1. 2  Cheeking  a  Necessary  Condition 

Another  special  case  of  checking  for  special  cases  is  checking  far  necessary  conditions.  A  rule  that 
docs  this  has  the  form  c  ->  nil  if  ~C,  where  C  is  a  necessary  condition  for  e.  Some  intersection  search 
rules  have  this  form  (§5.6),  with  the  existence  of  a  path  through  some  network  as  die  necessary 
condition  for  e.  Another  rule  of  this  form  checks  a  necessary  condition  for  an  element  to  be  in  a  set. 
namely  that  it  not  lie  beyond  the  extremum  defined  by  an  ordering  («.*.&.  if  the  richest  member  of  a 
club  is  worth  a  million  dollars,  J.  Paul  Getty  doesn’t  belong  to  it): 

RUI.F304:  (in  c  S)  ->  nil  if  (R  c  (f  S)),  where  R  is  an  ordering  and  (f  S)  is  R-extrcmum  of  S 


RULH3Q4  says  a  tone  can’t  have  been  used  In  a  cantus  if  adding  it  alters  the  climax: 
(IN  (NEXT  NOTE)  CANTUS-t) 

14:73-75  ---  [REDUCE  by  RULE304.  analysis]  ---> 

NIL 
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Here  R  =  HIGHER,  f  =  HIGHEST.  The  analysis  checks  that  the  added  note  is  higher  than  the 
current  climax: 

(HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1)) 

14:74  —  [by  a  premise  of  the  case  under  consideration]  — > 

T 


5.9.2.  Reduction  Without  Analysis 


Some  reduction  rules  have  conditions  that  can  be  tested  without  analysis.  Of  these  rules,  some 
preserve  semantic  equivalence  but  do  not  qualify  as  simplification  rules  because  there  arc  situations 
in  which  applying  diem  is  a  bad  idea.  Others  transform  expressions  into  simpler  but  non-equivalent 
ones,  typically  sufficient  conditions. 


5.9.2.1  Heuristic  Equivalence-Preserving  Reduction 


Some  reduction  rules  preserve  semantic  equivalence  but  arc  not  always  useful.  The  recognition 
rules  discussed  earlier  (§5.8.3)  are  like  this.  They  transform  expressions  into  simpler  equivalent  ones, 
but  should  not  be  applied  whenever  applicable,  e.g.,  immediately  after  expanding  the  definition  of  a 
concept.  Another  example  of  a  heuristic  equivalence-preserving  reduction  rule  is 

RULE21J:  ([lambda  (xL ...  xn)  e]  eL ...  en)  ->  c\ 

where  e'  is  die  result  of  substituting  et ...  cn  for  x( ...  xn  throughout  e 

This  rule  is  useful  in  DHRIV14: 

([LAMBDA  (J)  (NOTE  (+  J  1))]  Tl) 

14:86  ---  [SIMPLIFY  by  RULE213]  ---> 

(NOTE  (+  Tl  1)) 


However,  applying  it  whenever  possible  would  prevent  the  following  important  step  in  DHRIV2: 

( HSM1  WITH 

(RE FORMULATED- PR08LEM  : 

([LAMBDA  (CAR0S-PLAYED1 ) 

(AND  [HAVE-POINTS  CARDS -PLAYED  1] 

[«  (CARDS-PLAYE01  ME) 

(HIGHEST- IN-SUIT -LED  CARDS -PLAYED  1 )]) ] 
(CARDS-PLAYED)))) 

14:22  ---  [by  RULE317]  ---> 

HSM 1  <-  SOLUTION-TEST  : 

(LAMBDA  (CARDS-PLAYED1) 

(AND  [HAVE-POINTS  CAR0S-PLAYED1] 

[=  (CAR0S-PLAYED1  ME) 

(HIGHEST- IN-SUIT -LED  CARDS-PLAYED  1 )]) ) 


§5.9.2. 1.  Heuristic  Equivalence-Preserving  Reduction 
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The  reason  is  that  the  reduction  made  by  RULE213  would  render  RU1.E317  inapplicable: 

([LAMBDA  (CARDS-PLAYE01) 

(AND  [HAVE-POINTS  CARDS -PLAYED1 ] 

[=  (CAR0S-PLAYED1  ME) 

(HIGHEST- IN-SUIT -LED  CARDS -PLAYED1)])] 

(CARDS-PLAYEO) ) ) ) 

—  [by  RULE213]  ---> 

(ANO  [HAVE-POrNTS  (CARDS-PLAYED) ] 

[  =  ((CARDS-PLAYED)  ME) 

(HIGHEST-IN-SUIT-LED  (CARDS-PLAYED))]) 


Thus  it  would  not  be  safe  to  incorporate  RULE213  in  a  canonicalization  procedure  applied 
automatically  after  every  transformation,  since  doing  so  would  make  it  impossible  to  get  expressions 
into  tire  non-canonical  form  required  by  Rl'l.F.317  (§5.2.5). 


Other  equivalence-preserv  ing  reduction  rules  arc  listed  below  with  examples  of  their  use. 
lU.il.E215:  (lambda  (x)(fx))->  f 

(LAMBDA  (EXISTS! )  (NOT  EXISTS1)) 

9:15  ---  [SIMPLIFY  by  RULE215]  ---> 

NOT 


RLTE290:  (R  [+  e  kj  k.,)  ->  (R  e  k),  where  R  is  an  arithmetic  relation  and  k  =  k(  -  k2 

(=  [+  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1]  1) 

14:27  ---  [REDUCE  by  RULE29Q ]  ---> 

(=  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CAHTUS-1)  0) 


RUL.F.374:  (before  A  l!)  ->  R,  where  B  is  a  boolean  constant  (T  or  nil) 

(BEFORE  (CURRENT  ROUND- IN  -  PROGRESS )  NIL) 

10:20  ---  [EVAL  by  RULE374]  ---> 

NIL 


5.9.2.2  Reduction  to  a  Sufficient  Condition 

Some  problem  reduction  rules  e  ->  o'  don't  guarantee  that  o'  is  semantically  equivalent  to  c.  They 
typically  guarantee  only  that  e’  is  a  sufficient  condition  for  c.  :. c. .  drat  e'  implies  c.  Such 
transformations  arc  common  in  planning,  i.e..  transforming  a  goal  into  a  plan  whose  execution  is 
sufficient  to  achieve  it  (the  generated  plan  need  not  be  die  only  way  to  achieve  the  goal).  Partial 
matching  often  reduces  an  expression  to  a  sufficient  condition  (§5.3.3). 

Reduction  to  a  sufficient  condition  is  illustrated  in  DERIYll,  where  die  problem  is  to  find  a 
sufficient  condition  for  deducing  that  an  opponent  P0  is  void  in  suit  50.  fire  chosen  approach  takes  a 
known  fact  about  the  game,  namely  (LEGAL  Pi  (CARD-OF  Pi) ),  and  determines  when  it  implies 
(VOID  P0  SO)  (§2.6.2).  The  goal  is  to  find  an  evaluable  •sufficient  conJu-.cn  for 
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(=>  [LEGAL  PI  (CARD-OF  PI)]  [VOID  PO  SO]) 


The  first  step  is  to  expand  the  definition  of  LEGAL: 

(LEGAL  PI  (CARO-OF  PI)) 

11:7  ---  [ELA80RATE  by  RULE  124]  ---> 

(ANO  [HAS  PI  (CARD-OF  PI)] 

[=>  (LEADING  PI) 

(OR  [CAN-LEAD-HEARTS  PI] 

[NEQ  (SUIT-OF  (CARD-OF  PI))  H])] 

[=>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)] 

[IN-SUIT  (CARD-OF  PI)  ( SU IT -LED ) ] ) ] ) 


♦ 


« 


The  next  three  steps  reduce  the  expression: 


(=>  [AND  [HAS  PI  (CARD-OF  PI)] 

[=>  (LEADING  PI) 

(OR  [CAN-LEAD-HEARTS  PI] 

[NEQ  (SUIT-OF  (CARD-OF  PI))  H])] 

[=>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)] 

[IN-SUIT  (CARO-OF  PI)  ( SUIT -LED) ]) ]] 

[VOID  PO  SO]) 


11:8 


---  [REDUCE  by  RULE224]  ---> 

(*>  [=>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  (CARD-OF  PI) 

(SUIT-LED)])] 

[VOID  PO  SO]) 


11:9 


---  [REDUCE  by  RULE226]  ---> 

(AND  [FOLLOWING  PI] 

[=>  [OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  (CARD-OF  PI) 

(SUIT-LED)]1 

[VOID  PO  SO]]) 


(=>  [OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  (CARD-OF  PI) 

(SUIT-LED)]] 

[VOID  PO  SO]) 

11:10  ---  [REDUCE  by  RULE225]  ---> 

(ANO  [NOT  (OR  [IN-SUIT  (CARO-OF  PI)  ( SU  IT -LED )  ]  )  ] 
[=>  [VOID  PI  (SUIT-LED)]  [VOID  PO  SO]]) 


At  this  point,  partial  matching  can  reduce  die  implication  to  a  conjunction  of  equalities: 

(=>  [VOID  PI  (SUIT-LED)]  [VOID  PO  SO]) 

11:11  ---  [DISTRIBUTE  by  RULE43]  ---> 

(AND  [=  PI  PO]  [=  (SUIT-LED)  SO]) 


Solving  for  PI  and  simplifying  gives  the  desired  expression: 


t 


« 
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(AND  [FOLLOWING  PI] 

[AND  [NOT  (OR  [IN-SUIT  (CARD-OF  PI)  (SUIT-LED)])] 
[AND  [=  PI  PO]  [=  (SUIT-LED)  SO]]) 

11:12-17  ---  [by  analysis]  ---> 

(ANO  [NOT  (IN-SUIT  (CARO-OF  PO)  (SUIT-LED))] 

[=  (SUIT-LED)  SO] 

[FOLLOWING  PO]) 


In  short,  a  sufficient  condition  for  deducing  player  PO  to  be  void  in  suit  SO  is  that  PO  play  a  card  in 
a  suit  other  than  the  suit  led  when  the  suit  led  is  SO  and  PO  is  not  leading.  (The  last  condition  follows 
from  the  first,  of  course:  by  definition,  the  leader’s  card  is  in  the  suit  led). 

5.9. 2.2.1  Relevant  Implication  and  Reduction  to  a  Sufficient  Condition 

Reduction  played  a  key  role  in  the  above  example  by  transforming  the  expression  so  as  to  enable 
partial  matching.  Reduction  doesn't  always  preserve  logical  equivalence;  often  it  transforms  e  ->  c’ 
w'hcrc  c'  only  implies  e.  The  non-equivalence  shows  up  when  e  =  T  but  e’  -  NIL,  which  occurs  in 
the  following  aues  for  the  cases  indicated: 

RULF224:  ( =  >  [and  C[ ...  C  ...  CJ  [P ...])  ->  ( =  >  C  [P  ...])  if  P  occurs  in  C 
-  take  Cl  =  (P...)  =  NIL 

RCLE225:  (  =  >  [or ...  C  ...]  [P  ...])  ->  (and  [not  (or  ...)][  =  >  C  (P  ...)])  if  P  occurs  in  C 
--  take  (P  ...)  =  C’  =  T  for  some  C  other  than  C  in  (or ...  C ...) 

RU1.F.226:  (  =  >[  =  >  R  C|  [P  ...])  ->  (and  R  [=>C(P ...)[)  if  P  occurs  in  C 
--  take  R  =  NIL,  (P  ...)  =  T 


The  non-equivalence  has  to  do  with  the  relevance  of  P  to  C.  For  instance,  if  (and  C(  ...  C  ...  Cn) 
implies  (P  ...)  in  RULF224,  it  should  be  because  C  is  line,  since  P  occurs  in  C  and  is  therefore 
presumably  relevant  to  it.  Similarly,  if  (or ...  C  ...)  implies  (P  ...)  in  RUI.K225,  it  should  be  because  C 
is  true,  which  must  -ertainly  be  the  case  if  the  other  terms  in  the  disjunction  arc  false.  Although  some 
of  roo’s  rules  treat  the  connective  =>  as  standard  predicate  calculus  implication  (where,  for  instance, 
NIL  =o  P  is  true  for  any  P),  the  reduction  rules  above  treat  it  more  like  the  relevant  implication  of 
relevance  logic  [A  nderson  75],  where  P  =  >  Q  is  false  unless  P  is  relevant  to  Q. 

Other  rules  for  reduction  to  a  sufficient  condition  arc  listed  below  with  examples  of  their  use. 

RUI.E172:  (in  (f  c)  (project  f  S))  ->  (in  e  S)  --  equivalent  iff  is  injective 

(IN  (HAND  ME)  (PROJECT  HANO  (PLAYERS))) 

<1:23  ---  [REMOVE-QUANT  by  RULE  1 72]  ---> 

(IN  ME  (PLAYERS)) 
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(IN  (CARD-OF  ME)  (PROJECT  CARO-OF  (PLAYERS))) 
5:23  ---  [REMOVE-QUANT  by  RULE172]  ---> 

(IN  ME  (PLAYERS)) 


RULE193:  ( =  Px  (in  x  S))  ->  (=  S  [set-of  x  [domain  x  PJ  PJ) 

(  =  (IN-SUIT  Cl  SO)  (IN  Cl  SI)) 

9:7  ---  [by  RULE  193 ]  ---> 

(=  SI  [SET-OF  Cl  [OOMAIN  Cl  (IN-SUIT  Cl  SO)]  (IN-SUIT  Cl  SO)]) 


RULE193  initiates  a  search  for  the  domain  (Le„  type)  (§5.5.3)  of  variable  x  in  order  to  find  an 
evaluable  superset  of  S  (§2.3. 1.4). 

RUI.E277:  (change  (f  S))  ->  (R  [f  (change  S)]  [f  S])  --  equivalent  i/S  is  expanding 

(CHANGE  (HIGHEST  CANTUS-1)) 

14:42  ---  [REDUCE  by  RULE277]  ---> 

(HIGHER  [HIGHEST  (CHANGE  CANTUS-1)]  [HIGHEST  CANTUS-1]) 


Here  (f  S)  is  the  extreme  element  of  S  with  respect  to  ordering  R,  and  CHANGE  is  ambiguous: 
(change  (f  S))  is  true  iff  (f  S)  *  (next  (f  S)),  but  (change  S)  denotes  (diff  (next  S)  S). 

5.9.2.3  Reduction  to  a  Necessary  Condition 

A  reduction  rule  e  ->  e’  may  guarantee  only  chat  e'  is  a  necessary  condition  for  e.  Such  is 
RU1.E369:  (in  e  (set-of  x  S  Px))  ->  Pe  --  equivalent  if  (in  e  S) 

RULE369  is  used  in  DER1V9  to  make  the  reduction 

(IN  X2  (SET-OF  C4  (CARDS)  (HAS  PO  C4))) 

9:30  ---  [REMOVE-QUANT  by  RULE369 ]  ---> 

(HAS  PO  X2) 


The  reduced  expression  docs  not  test  whether  X2  is  in  (CARDS).  RUI.H369  collapses  into  a  single 
step  the  sequence 

(in  c  (set-of  x  S  Px)) 

->  (and  [in  e  S]  PJ  --  propagate  S-P  split  (preserves  equivalence) 

->  (and  T  P^)  --  assume  (in  e  S) 

->  Pfi  --  simplify 


Another  rule  for  reducing  an  expression  to  a  necessary  condition  is 
RULE350:  (achieve  (and  ...  P  ...))  ->  (achieve  (and  ...)) 


RULF.350  preserves  equivalence  if  the  right-hand  conjunction  implies  P. 


§5.9.2. 3.  Reduction  to  j  Necessary  Condition 
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it  is  used  in  DKRIV3  to  eliminate  an  unnecessarily  specific  clause  generated  in  planning: 

(ACHIEVE  (AMD  [PLAY  (QSO)  C3] 

[=>  (FOLLOWING  ( QSO) )  (IN-SUIT  C3  S)] 

[IN  C3  (DIFF  (CARDS)  (SET  QS ) ) ] ) ) 

3:81  ---  [by  RULE350]  ---> 

(ACHIEVE  (AND  [PLAY  (QSO)  C3] 

[O  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)])) 


The  condition  ( IN  C3  (DIFF  (CAROS)  (SET  QS) ))  can  be  dropped  since  the  goal  of  Hushing 
the  Queen  does  not  require  C3  #  QS. 


Another  rule  reduces  an  expression  to  a  necessary  condition  by  substituting  e2  for  Cj  based  on  an 
equality  et  =  e2  given  in  the  problem: 

RUI.E354:  (and  ...  [=  e2] ...  [P  ...  ej ...] ...)  ->  (and  ...  [=  c\] ...  [P  ...  e2  ...] ...) 


RULE354  substitutes  ME  for  (LEADER)  in  DHRIV3  and  DKRIV5: 

(AND  [=  (LEADER)  ME]  [SPAOE !  (CARD-OF  (LEADER))]) 

3:95  ---  [by  RULE354]  ---> 

(AND  [=  (LEADER)  ME]  [SPADE!  (CARD-OF  ME)]) 

(AND  [=  (LEADER)  ME] 

[SPAOE!  (CARD-OF  ME)] 

[NOT  (AND  [IN  QS  ( CARDS  -  PLAYED) ] 

[AND  [=  (SUIT-OF  (CARD-OF  ME)) 

(SUIT-OF  (CARD-OF  (LEADER)))] 
fr0RALL  XI 

(CARDS- IN-SUIT -LED  ( CARDS- PLAYED ) ) 
(NOT  (HIGHER  XI  (CARD-OF  ME)))]])]) 

5:32  ---  [by  RULE354]  ---> 

(AND  [=  (LEADER)  ME] 

[SPADE!  (CARD-OF  ME)] 

[NOT  (AND  [IN  QS  ( CARDS  -  PLAYED ) ] 

[AND  [--  (SUIT-OF  (CARD-OF  ME)) 

(SUIT-OF  (CARD-OF  ME))] 

[FORALL  XI 

(CARDS- IN-SUIT-LED  ( CARDS- PLAYED )  ) 
(NOT  (HIGHER  XI  (CARD-OF  ME)))]])]) 


RL  I.F.354  can  be  characterized  as  propagating  an  assumption  (§5.4.3). 

5. 9.2.4  Reduction  to  a  Non-equivalent  Expression 

For  some  reduction  rules  e  ->  e’,  e'  is  neither  necessary  nor  sufficient  for  c,  as  in 
RLLE238:  (choose  c  S  E^  ->  Ec 

RULE238  is  used  to  discard  superfluous  information  preventing  recognition  of  PROJECT: 
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(EACH  12  ( LB : UB  1  (CANTUS-LENGTH) ) 

[CHOOSE  (MOTE  12)  (TONES)  (NOTE  12)]) 

13:13  ---  [REDUCE  by  RULE238]  ---> 

(EACH  12  (LB.-UB  1  ( CANTUS-LENGTH ) )  (NOTE  12)) 
13:14  ---  [RECOGNIZE  by  RULE  123 ]  ---> 

(PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))) 


The  c  in  (choose  c  S  E£)  is  by  convention  a  composite  name  containing  enough  information  to 
retrieve  the  choice  event  itself  (§2.7);  thus  RULE238  doesn't  really  lose  information  in  the  way  that  a 
transformation  like  (exists  x  S  Px)  ->  P  would. 

Another  reduction  transformation  that  doesn’t  preserve  semantic  equivalence  is  given  by 
RULE366:  (achieve (...  (previous  e) ...))  ->  (achieve  (...  e  ...)) 


RULE366  is  used  in  DF.RIV7  in  constructing  a  plan  to  get  the  lead: 

(ACHIEVE  (LEADING  ME)) 

7:1-2  ---  [ELABORATE  by  RULE  124]  ---> 

(ACHIEVE  (=  (PREVIOUS  (TRICK-WINNER))  ME)) 

7:3  ---  [by  RULE366]  ---> 

(ACHIEVE  (=  (TRICK-WINNER)  ME)) 

RUI.E366  expresses  the  simple  idea  that 

What  is  now  the  present  will  become  the  past  in  the  future. 

You  can’t  make  something  happen  yesterday  (without  travelling  back  through  time),  but  if  you 
make  it  happen  today,  tomorrow  you  will  be  able  to  say  "it  was  true  yesterday."  In  the  example  at 
hand,  you  can’t  make  yourself  win  the  previous  trick,  but  if  you  win  the  current  trick,  you'll  lead  the 
next  one.  The  explanation  is  more  complicated  than  the  idea;  English  is  an  awkward  language  for 
expressing  concepts  like  "what  ‘yesterday’  will  mean  tomorrow.” 


5.9.3.  Discussion 

T  his  section  has  thus  far  classified  reduction  ailes  c  ->  o'  if  C  according  to  two  criteria: 

1.  The  difficulty  of  evaluating  C;  docs  it  require  analysis? 

2.  The  logical  relationship  of  e’  to  c:  arc  they  equivalent?  does  one  imply  the  other? 

In  some  ways  these  distinctions  are  superficial.  In  particular,  one  can  change  the  classification  of  a 
rule  e  ->  e’  if  C  simply  by  making  tire  condition  C  an  assumption  or  incorporating  C  in  o’.  The 
following  discussion  explains  how  some  of  these  connections  arc  exploited  in  COO. 


§5.9.3. 1.  Reduction  Rased  on  Assumption 
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5.9.3. 1  Reduction  Based  on  Assumption 


Consider  an  equivalcnce-prcscr\ing  rule  of  die  form 


e  ->  c’  if  C 


Assume  the  rule  requires  analysis  to  check  for  the  special  case  C  (§5.9.1).  Now  consider  the  rule 
e  ->  e’  assuming  C 

Although  almost  identical  to  the  first  rule,  it  is  classified  quite  differently,  since  it  requires  no 
analysis  and  is  not  guaranteed  to  preserve  semantic  equivalence  (§5.9.2.3). 

FOO  has  a  rule  that  allows  it  to  treat  the  first  kind  of  ailc  as  if  it  were  the  second: 

RU1.E32:  e  ->  e’  assuming  C',  if  the  condition  C  of  some  rule  c  ->  c'  has  been  reduced  to  C’ 


RULE.32  is  used  in  DF.RIV2  to  make  the  reduction 

(a  (HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS))) 
(HIGHEST- IN-SUIT -LED  CARDS- PLAYED1 ) ) 

2:63-64  ---  [REOUCE  by  RULE322 ,  ASSUME  by  RULE32]  ---> 
(IN  (HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS)) 
CAR0S-PLAYED1) 


This  is  done  by  assuming  the  unproved  condition  of  RULE322: 

(SUBSET  CARDS-PLAYE01  (PROJECT  CARD-OF  (PLAYERS))) 
2:64  ---  [ASSUME  by  RULE32]  ---> 

T 


RU1.F.32  is  also  used  in  DF.R1V9  to  make  the  refinement 

(PR-DISJOINT  (CAROS- IN-HAND  PO)  ( CARDS- I N-SUIT  SO)  (CARDS)) 

9:27-37  ---  [REFINE  ty  RULE200 ,  REOUCE  by  analysis]  ---> 
(PR-DISJOINT  (CAROS- IN-HAND  PO)  ( C ARDS-OUT - 1 N- SU I T  SO)  (CARDS-OUT)) 


Here  the  reduced  condition  of  RUEH2Q0  is  assumed: 

(=  ( CARDS- IN-HAND  PO)  (FILTER  ( CARDS  -  IN-HAND  PO)  OUT)) 
9:28-36  ---  [REDUCE  by  analysis]  ---> 

(IN  PO  (OPPONENTS  ME)) 

9:37  ---  [ASSUME  by  RULE32]  ---> 

T 


RULE32  could  be  used  as  part  of  die  following  strategy  for  making  plausible  assumptions: 


1.  Given  a  potentially  useful  reduction  c  ->  e'  if  C,  try  to  prove  C. 
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2.  If  you  reduce  C  to  C’  but  can't  prove  or  disprove  C’,  assume  C’  and  reduce  e  to  e’. 

The  idea  here  is  that  an  incomplete  proof  of  C  shouldn't  be  wasted,  since  completing  it  may  only  y 

require  a  tact  not  in  the  knowledge  base,  like  ( SU8SET  CARDS-PLAYED1  (CARDS-PLAYED))  in  the 
first  example,  or  a  reasonable  restriction  on  the  solution,  like  (IN  PO  (OPPONENTS  ME))  in  the 
second.  One  way  to  exploit  such  as  incomplete  proof  is  to  assume  C  and  reduce  e  to  e’.  An 
alternative  is  to  use  some  other  means  to  ascertain  C\  For  example,  an  empirical  approach  would  test 
C’  in  several  actual  task  situations  to  see  if  it  were  true  in  all  of  them  (§8.1.7). 

5.93.2  Exploiting  Special  Case  Near-Misses 

Often  a  special-case  rule  e  ->  e’  if  C  is  almost  applicable  to  a  given  expression,  Le.,  C  reduces  to  a 
much  simpler  condition  C.  Even  when  C  can’t  be  proved,  the  rule  can  still  be  useful  in  such  special- 
case  near-miss  situations  if  C  is  treated  as  an  assumption,  as  a  restriction  on  the  solution,  or  as  an 
additional  subgoal  to  be  achieved. 

5.9.3.2.1  Reducing  a  Coal  to  a  Feasible  Subgoal 

Consider  a  rule  that  requires  analysis  to  check  a  sufficient  condition  C  for  e  (§5. 9.1.1): 
e  ->  T  ifC 

Consider  also  a  rule  that  reduces  e  to  a  sufficient  condition  without  analysis  and  is  not  guaranteed 
to  preserve  semantic  equivalence  (§5.9.2. 2): 

e  ->  C 

The  second  mle  subsumes  the  first  in  the  sense  that  if  the  first  rule  can  reduce  e  to  T,  so  can  the 
second.  In  the  first  case  C  would  reduced  to  T  during  verification  of  the  rule  condition,  while  in  the 
second  this  would  occur  after  the  rule  was  applied.  The  analysis  required  would  be  identical  in  the  > 

two  cases,  the  only  difference  being  whether  it  was  carried  out  as  a  subgoal  or  at  the  same  level  as  the 
original  problem. 

roo  has  a  rule  that  allows  it  to  treat  the  first  kind  of  rule  as  if  it  were  the  second:  y 

RULE151:  P  ->  R.  where  R  is  the  result  of  reducing  an  unproved  sufficient  condition  for  P 


RULF.151  is  used  in  DF.RIV6  to  make  the  reduction 


§5.9.3.2.1.  Reducing  a  Goal  to  a  Feasible  Subgoai 


279 


(HIGHER  (FIND-ELT  ( CAROS- IN- SUI T -L EO  (CAROS-PLAYED) ) ) 

(CARO-OF  ME)) 

6:44  ---  [TRY-THIS  by  RULE142]  ---> 

(AND  [IN  CARD1  ( CARDS- IN-SU I T - LED  (CARDS-PLAYED) )] 

[HIGHER  CARD1  (CARD-OF  ME)]) 

6:45-61  —  [reduce  by  analysis.  RULE151]  — > 

(HIGHER  OK  (CARD-OF  ME)) 

The  goal  of  making  (CARD-OF  ME)  'ower  than  some  card  played  in  the  suit  led  is  set  up  as  an 
equation  on  the  variable  CARD1.  Substituting  DK  for  CARDl  based  on  the  previous  assumption  that 
the  King  Oi  diamonds  is  led  (§5.4.4)  reduces  the  equation  to  (HIGHER  DK  (CARD-OF  ME) ).  This 
unprovablc  condition  is  adopted  in  place  of  the  original  goal,  and  the  advice  “avoid  taking  points"  is 
operationalized  as  "play  a  card  lower  than  the  King.” 

This  example  illustrates  die  following  strategy  for  generating/casiM’  subgoa/s: 

1.  Given  a  goal  G  and  a  sufficient  condition  rule  G  ->  T  if  C.  try  to  prove  C. 

2.  If  you  reduce  C  to  C’  but  can't  prove  or  disprove  C\  reduce  G  to  C'  and  achieve  C’. 

The  idea  here  is  that  an  unsuccessful  attempt  to  prove  a  desired  condition  may  reduce  it  to  a 
condition  that  satisfies  the  same  original  goal  but  is  easier  to  achieve. 

S.9.3.2.2  Finding  Restricted  Solutions 

RUI.E151  also  helps  find  restricted  solutions  to  problems.  For  example,  a  problem  in  DER1V2  is 
to  find  a  necessary  condition  for  a  player  PI  to  have  a  card  C2.  One  such  condition  is  that  the  card  be 
OUT,  but  this  solution  only  applies  when  PI  is  an  opponent  of  player  me: 

(=>  [HAS  PI  C2]  [OUT  C 7] ) 

2:29  ---  [ELABORATE  by  RULE124]  — -> 

(->  [HAS  PI  C2]  [EXISTS  P4  (OPPONENTS  ME)  (HAS  P4  C7 )  ] ) 

2:30  ---  [REDUCE  by  RULE322 ]  ---> 

(AND  [IN  P4  (OPPONENTS  ME)]  [=  PI  P4]  [=  C2  C7] ) 

2:31-37  —  [reduce  by  analysis,  RULE151]  — > 

(IN  PI  (OPPONENTS  ME)) 

Later  in  DRR1V2,  the  problem  arises  of  verifying  die  monotor.icity  condition  that  moving  a 
particular  test  earlier  in  a  heuristic  search  will  not  cause  any  potential  solutions  to  be 
discarded  (§3.4.1).  The  test  requires  diat  die  card  play  .d  by  player  ME  be  the  highest  card  in  the  suit 
led  in  die  card  sequence  CARDS-PLAYED1.  The  monotonicity  condition  reduces  to  die  restriction  that 
the  sequence  include  the  card  played  by  player  ME: 
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(=>  [=  ((PROJECT  CARO-OF  (PLAYERS))  ME) 

(HIGHEST- IN- SUtT-LED  (PROJECT  CARO-OF  (PLAYERS)))] 

[*  (CAROS-PLAYED1  ME) 

(HIGHEST -IN-SUIT -LEO  CARDS -PLAYED1 )] ) 

2:62  ---  [PARTIAL-MATCH  (=>  [«  ...]  [=  ...])  by  RULE91]  ---> 

(AND  [  =  ((PROJECT  CARO-OF  (PLAYERS))  ME)  (CARDS-PLAYED1  ME)] 

[-  (HIGHEST-IN-SUIT-LED  (PROJECT  CARO-OF  (PLAYERS))) 

( HIGHEST- IN-SUIT- LED  CARDS  -  PLAYED  1 )] ) 

2:63-72  ---  [reduce  by  analysis,  RULE151]  ---> 

(IN  ME  (INDICES-OF  CARDS-PLAYEOl ) ) 

This  restriction  is  incorporated  into  the  search  so  that  the  test  is  only  applied  to  sequences 
containing  player  ME's  card. 

This  example  illustrates  the  following  strategy  for  generating  restricted  solutions: 

1.  Given  a  problem  P  and  a  conditional  reduction  rule  P  ->  P‘  if  C,  try  to  prove  C. 

2.  If  C  reduces  to  an  unproved  condition  C,  reduce  P  to  P‘  and  adopt  C’  as  a  restriction. 

The  restricted  solution  is  one  that  solves  the  original  problem  P  only  when  some  additional 
constraint  C’  is  satisfied.  Restricted  solutions  can  be  useful  when  no  general  solutions  can  be  found. 
For  example,  there  is  no  general  way  to  tell  whether  an  opponent  is  void  in  a  suit,  but  there  arc 
several  methods  that  work  in  particular  special  cases,  such  as  when  the  opponent  has  previously 
broken  the  suit  in  question  (§2.6.2). 

5.93.2.3  Treating  a  Reduced  Rule  Condition  as  an  Additional  Subgoal 

If  the  original  problem  is  a  goal,  it  may  be  possible  to  treat  C’  as  an  additional  subgoal  rather  than 
as  a  restriction  on  the  applicability  of  the  solution: 

1.  Given  a  goal  G  and  a  conditional  reduction  rule  G  ->  G'  if  C,  try  to  prove  C. 

2.  If  C  reduces  to  an  unproved  condition  C’,  reduce  G  to  (and  G'  C')  and  achieve  this. 

The  particular  case  of  G'  =  T  corresponds  to  the  feasible  subgoal  strategy  (§5.93.2.1). 

5.9.4.  Problem  Reduction:  Summary 

Problem  reduction  can  profitably  be  compared  to  simplification.  A  simplification  rule  e  ->  e’  if  C: 

1.  Produces  an  expression  e'  simpler  titan  e,  Le..  smaller  and  easier  to  solve. 

2.  Preserves  the  semantic  equivalence  of  e  and  e'. 
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3.  Requires  no  analysis  to  evaluate  tire  condition  C. 

4.  Sever  hurts  to  apply,  since  it  doesn't  preclude  application  of  other  methods. 

In  contrast,  a  problem  reduction  rule  e  •>  e’  if  C: 

1.  Produces  tin  expression  e'  easier  to  analyze  than  e  but  not  always  smaller. 

2.  May  only  guarantee  e’  to  be  a  necessary  or  sufficient  condition  for  c. 

3.  May  require  analysis  to  check  for  the  special  case  C. 

4.  Is  hannful  when  it  gives  a  useless  result  or  prevents  application  of  other  methods. 

These  criteria  can  be  used  to  classify  problem  reduction  rules: 

1.  Analysis- hosed  reduction  rules  check  fora  special  case  and  preserve  equivalence  when  it  holds. 

a.  Rules  of  the  form  e  •>  T  if  C  check  a  sufficient  condition  C  for  c. 

b.  Rules  of  the  form  e  ->  nil  if  -C  check  a  necessary  condition  C  for  e. 

2.  Analysis-free  reduction  rules  can  be  harmful  to  apply,  or  fail  to  preserve  equivalence. 

a.  Heuristic  equivalence-preserving  reduction  interferes  with  other  rules  if  used 
indiscriminately. 

b.  Reduction  to  a  sufficient  condition  is  useful  in  planning  and  relates  to  relevant  implication. 

c.  Reduction  to  a  necessary  condition  exploits  implicit  or  explicit  assumptions. 

d.  Reduction  to  a  non- equivalent  expression  transforms  the  problem  to  make  it  solvable. 

Problem  reduction  subsumes  some  kinds  of  rules  described  by  other  names.  For  example, 
recognition  (§5.8.3)  is  heuristic  equivalence-preserving  reduction,  since  it  interferes  with  other 
methods,  e.g..  elaboration.  Partial  matching  (§5.3)  is  often  reduction  to  a  sufficient  condition. 
Intersection  search  (§5.6)  is  often  used  to  check  a  necessary  condition. 

The  criteria  used  in  this  classification  arc  somewhat  superficial  in  that  a  rule  classified  in  one 
category  may  be  functionally  very  similar  to  one  in  a  completely  different  category,  roo  has  some 
rules  whose  effect  is  the  same  as  transforming  a  rule  c  ->  c"  if  C  from  one  category  to  another: 

1.  Reduction  by  assumption  eliminates  analysis  by  assuming  C.  possibly  violating  equivalence. 

2.  Reduction  by  special-case  near-miss  reduces  C  to  an  assumption,  restriction,  or  subgoal. 


282 


§5.  Analysis  Methods 


5.10.  Restructuring 


A  common  lactic  in  solv  ing  a  problem  is  to 

Restructure  the  problem  so  that  other  methods  can  be  applied. 


Restructuring  an  expression  means  rearranging  its  components,  as  opposed  to  translation  (§5.8), 
which  reformulates  it  in  terms  of  different  concepts.  Thus  a  restructured  expression  usually  contains 
the  same  symbols  as  the  original,  although  minor  changes  in  vocabulary  may  be  required  to  preserve 
syntactic  well-formedness  or  semantic  consistency.  For  example,  two  restructuring  rules  are: 

RULF.58:  (during  [each  x  S  F.  ]  A)  ->  (exists  x  S  [during  F.  A])  --  extract  EACH 

RUI.F.100:  (during  A  [for-some  x  S  HJ)  ->  (exists  x  S  [during  A  EJ)  -  extract  FOR-SOME 


These  rules  help  in  analy  zing  whether  player  ME  takes  points  when  the  w  inner  takes  the  trick: 
(DURING  [TAKE-TRICK  (TRICK-WINNER)]  [TAKE-POINTS  ME]) 

6:7-8  ---  [ELABORATE  by  RULE  124]  ---> 

(DURING  [EACH  C3  ( CARDS-PLAYEO)  (TAKE  (TRICK-WINNER)  C3)] 

[FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl)]) 

6:9  ---  [RESTRUCTURE  by  RULE58]  ---> 

(EXISTS  C3  (CAROS-PLAYED) 

(OURING  [TAKE  ( TR ICK- WTNNER )  C3] 

[FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl)])) 

6:10  ---  [RESTRUCTURE  by  RULE100]  ---> 

(EXISTS  C3  (CAROS-PLAYED) 

(EXISTS  Cl  ( PO INI- CAROS  ) 

(DURING  [TAKE  (TRICK-WINNER)  C3]  [TAKE  ME  Cl]))) 

6:11  ---  [REDUCE  by  RULE43]  ---> 

( EX  TSTS  Cl  (CARDS-PLAYED) 

(EXISTS  Cl  (POINT-CARDS) 

(AND  [=  (TRICK-WINNER)  ME]  [=  C3  Cl]))) 


The  idea  here  is  to  reduce  the  problem  by  partial  matching.  First  both  arguments  of  die  initial 
expression  are  elaborated  in  terms  of  a  common  concept  TAKE,  introducing  the  quantifiers  EACH  and 
FOR-SOME.  To  put  the  expression  in  the  desired  form  (DURING  [TAKE  ...]  [TAKE  .  .  .  ] ) .  the 
quantifiers  arc  moved  outside  by  the  restructuring  rules,  changing  EACH  and  FOR-SOME  to  EXISTS  in 
the  process.  The  restructured  expression  is  reduced  by  partial  matching,  and  the  resulting  expression 
is  subsequently  simplified. 


RUI.H58  arid  RU1 F100  perform  a  kind  of  restructuring  transformation  called  junction 
transposition  because  they  transpose  the  order  in  which  two  functions  f  and  g  arc  applied,  they 
have  the  form 
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If...  (g  ...]  ...)->  (g’ ...  [f  — 1  — ) 

In  steps  6: 9-10.  f  =  OURING.g  =  EACH  and  fOR -SOME  respectively,  and  g'  =  EXISTS. 

This  section  is  o^anized  as  follows.  (§5.10.1)  describes  TOO’s  rules  for  function  transposition. 
(§5.10.2)  describes  rules  that  transfer  in  formation  from  to  e.  in  an  expression  of  the  form  (f  ej  ...  cn). 
(§5.10.3)  describes  rules  that  convert  functions  into  functionals  and  vice  versa  by  moving  information 
between  an  argument  e(  and  the  function  f,  which  may  be  a  non-atomic  expression.  (§5.10.4) 
summarizes  the  differences  and  similarities  among  the  three  kinds  of  restructuring  rules. 

5.10.1.  Function  Transposition 

In  general,  function  transposition  is  a  restructuring  transformation  of  die  form 

(f -  (g  • -1  -)->  ...If...]...) 

If  the  initial  expression  is  (f  e( ...  en).  the  function  symbol  f  may  be  transposed  with  g  in  one,  some, 
or  all  the  arguments  e(.  A  sub-expression  (g  ...)  may  be  a  top-lcvcl  component  e)  of  (f  e(  ...  en),  or  it 
may  be  nested  within  cr.  Transposition  with  g  =  g’  is  called  pure,  as  distinguished  from  quasi- 
transposition. 

Transposition  has  some  special  cases.  Distribution  transposes  f  with  g  in  two  or  more  arguments: 

(f ...  [g  et  ...  cn] ...)  ->  (s’  [f ...  c,  ...I ...  [f ...  en  ...j) 

This  kind  of  transformation  is  useful  for  propagating  splits  in  problems  (§5.7.5).  The  inverse  of 
distribution  is  collection'. 

(f  [g  ...  et ...] ...  [g  ...  cn  ...])  ->  (g- ...  [f  Cj  ...  cnJ ...) 

Transposing  f  with  g  in  a  single  sub-expression  is  called  embedding  f  or  extracting  g: 

(f  Cj ...  [g  SA ...  Sk] ...  Cn)  ->  (g-  st ...  [f  e, ...  s. ...  e„l ...  \) 

If  ej  in  (f  Cj  ...  e;  ...  cn)  is  (g  sA  ...  s  ...  sk),  embedding  f  produces  (g-  s(  ...  s.’  ...  sfc).  where  s.'  is 
(f  ex ...  Sj ...  en).  That  is,  f  and  all  its  arguments  c1 ...  en  except  e;  are  embedded  in  the  subexpression  e.( 
=  (g  s1 ...  s. ...  Sj,)  by  replacing  Sj  with  (f  c{  ...  s^  ...  en).  Equivalently,  g  and  all  its  arguments  s}  ... 
except  s  arc  extracted  from  (f  Cj  ...  en)  bv  replacing  e|  with  s  .  and  become  top-level  components  of 
the  new  expression,  with  g  possibly  changed  to  g'.  Transposition  is  even  harder  to  describe  in  English 
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when  (g  s1 ...  sk)  is  nested  within  et; 


the  general  idea  is  that  it 


9 


m  'my  •  ‘  '«**'  m  ‘  m  /  m  i  '  ■. 'm 'l  H  N „  /  ■■■'« 

Fortunately,  these  transformations  can  be  diagrammed  quite  simply  as  splicing  operations  on  trees 
with  labelled  nodes,  where  an  expression  (f  Cj  ...  cn)  is  represented  as  a  tree  with  root  labelled  f  and 
offspring  representing  ej  ...  en.  In  this  representation,  function  transposition  corresponds  to  a 
structural  transformation  described  in  the  early  literature10: 


--  <  /  <'n  '~<M  •  I'm*  f  /  <’  >nn 


Figure  5-1  illustrates  the  three  kinds  of  function  transposition  described  above  (distribution, 
collection,  and  embedding/extraction). 


As  a  problem-solving  tactic,  transposition  brings  one  concept  towards  contact  with  (direct 
application  to)  another  by  removing  an  intervening  function,  either  embedding  it  tit  a  deeper  level  of 
nesting  or  extracting  it  to  a  higher  one.  In  the  earlier  example,  the  quantifiers  FOR-SOME  and  EACH 
were  extracted  to  bring  OURING  into  contact  with  TAKE  for  partial  matching.  In  the  following 
example  from  DHRIV3,  the  function  DIFF  is  embedded  to  bring  REMOVE-  1-from  in  contact  with 
SET -of  so  RULE?  can  be  used: 

( REMOVE  - 1-FROM  (DIFF  [LEGALCAROS  (QSO)]  [SET  QS]) 

3:39  ---  [ELABORATE  by  RULE  124]  ---> 

(REMOVE -1-FROM  (DIFF  [SET-OF  C3  (CAROS)  (LEGAL  (QSO)  C3 ) ] 

[SET  QS])) 

3:40  ---  [EMBED  by  RULE5]  ---> 

( REMOVE  -  1  -  FROM  (SET-OF  C3  [DIFF  (CARDS)  (SET  QS)]  (LEGAL  (QSO)  C3 ) ) ) 

3:41  ---  [PROPAGATE-SPLIT  by  RULE  7  ]  ---> 

(UNDO  (AND  [IN  C3  (DIFF  (CARDS)  (SET  QS))]  [LEGAL  (QSO)  C3] ) ) 


This  embedding  is  accomplished  by  the  transposition  rule 

RULE5:  (diff  (set-ofx  PJ  $,)  ->  (set-of  x  [diff  S1  S.J  P^)  -  embed  DIFF 


roo's  ocher  transposition  rules  arc  listed  below  with  examples  of  their  use.  Underlining  indicates 
correspondence  between  rule  variables  and  components  of  expressions. 


a 

bnngcst  low  the  haughty  and  raisest  up  the  lowly  ...  tcadesi  Forth  the  captives  and  delivcrcst  the  meek.  [From  a  M.shnaie 
1 300  B  C.-IOO  A  D  )  prayer  in  the  daily  morning  service] 

in 

t  have  made  low  the  high  tree,  have  made  high  the  low  tree  (toekiel  17:34), 
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f  --- 

/  i  \ 

/  i  \ 

/  i  \ 

g 

/|\ 

/  I  \ 

/  I  \ 

el  ...  en 


g' 

\  / 1  \ 
DISTRIBUTE  f  /  j  \ 

\  /  I  \ 

\  /  I  \ 

--->  f  ...  f 
/|\  /|\ 

/  |  \  /  |  \ 

/  |  \  /  I  \ 

...  el . en 


f 

/|\  / 

/  |  \  COLLECT  g 
/  |  \  / 

/  l  \  / 

g  ...  g  — 

/|\  / 1\ 

/  |  \  /  j  \ 

/  |  \  /  |  \ 

.  el  . en  ... 


-->  g* 

/|\ 

/  I  \ 

'  I  \ 

/  I  V 

f 

/[X 
/  I  \ 

/  I  \ 

el  ...  en 


f  -- 

•  I  \ 

t  I  ' 


/  I  N 
/  I  \ 


. -*>  9* 

\  /  )\\ 

\  /  /  I  \ 

embed  f  /  |  \ 
EXTRACT  g  /  |  \ 

/X  /  I  \ 


/  |  \  / 
el  ...  g  ...  en  -- 
/|\ 

/  I  \ 

si  ...  sk 


\  /  (  \ 
si  ...  f  ...  sk 

/  I  X 
el  sj  en 


Figure  5-1:  Transposition  of  f  and  g  in  (f...  (g ...) ...) 


RULE170:  (project  f[diff  S  S’])  ->  (diff [project  f  S]  [project  T  S’]), 

'■'•here  f  is  injective  --  distribute  PROJECT 

(PROJECT  HAND  [DIFF  (PLAYERS)  (SET  ME)]) 

4:12  ---  [DISTRIBUTE  by  RULE  170]  ---> 

(DIFF  [PROJECT  HANO  (PLAYERS)]  [PROJECT  HAND  (SET  ME)]) 


RULE220:  ( =  >  C  [Q  x  S  PJ)  ->  (Q  x  S  [=  >  C  PJ)  -  extract  Q 
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(=>  [HAS  PI  C 2 ] 

[EXISTS  CII  (CARDS) 

(AND  [HAS  P5  Cll]  [IN-SUIT  Cll  ( SUIT  -  LED )])] ) 

2:46  ---  [REDUCE  by  RULE220 ]  ---> 

(EXISTS  CU  (CARDS) 

[  =  >  (HAS  PI  C2)  (AND  [HAS  P5  Cll]  [IN-SUIT  Cll  (SUIT-LED )  ] ) ] ) 

RULE283:  (next  [g  ...  e  ...])  ->  (g  ...  [next  e] ...).  where  e  is  a  fluent  --  ewieJNEXT 

(NEXT  [=  f  ^OCCURRENCES  ( CLIMAX  CANTUS-1)  CANTUS-1)  1]) 

14:6  ---  [REDUCE  by  RULE283]  ---> 

(=  [NEXT  ( ^'OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-111  1) 

(NEXT  ( ^OCCURRENCES  (CLIMAX  CANTUS-11  CANTUS-1)) 

14:7  ---  [REDUCE  by  RULE233]  ---> 

( ^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-  1 1  1  (NEXT  CANTUS-1)  ) 


RULE296:  (and  ...  [not  C] ...  [not  C] ...)  ->  (and  ...  [not  (or  £  £1)1  •••)  •*  coilccl  NOT 


RULE296  generalizes  DeM organ's  law  (~A  and  ~B)  =  ~(A  or  B). 

(AND  [=  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  (NEXT  NOTE )  (CLIMAX  CANTUS-m] 

[NOT  (HIGHER  ( NEXT  NOTE)  (CLIMAX  CANTUS -1)11) 

14:47  ---  [COLLECT  by  RULE296 ]  ---> 

(AND  [»  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  (OR  THIGHER  (NEXT  NOT E 1  (CLIMAX  CAHTUS-m 
T»  (NEXT  NOTE  T  (CLIMAX  CANTUS- 111311 

RULE329:  i  P  ...  [Q  x  S  RJ  ...)  ->  (Q  x  S  [P  ...  Rx ...[)  -  extract  Q 

(O  (IN  ME  (INDICES-OF  CARDS-PLAYED1 ) ) 

(AND  [IN  (CAR0S-PLAYED1  ME)  ( CARDS- IN-SUIT-LED  CARDS  -  PLAYED  1 ) ] 
[FORALL  PI  (INDICES-OF  CARDS- PLAYED  1 ) 

(i>  (=  (SUIT-OF  (CAROS-PLAYED1  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEOl  PI) 

(CARDS-PLAYED1  ME))))])) 

2:81  ---  [by  RULE329]  ---> 

(FORALL  PI  (INDICES-OF  CARDS -PLAYED  1 ) 

[O  (IN  ME  (INOICES-OF  CARDS- PLAYED  1 ) ) 

(AND  [IN  (CARDS-PLAYED1  ME) 

(CARDS- IN -SUIT -LED  CARDS  -  PLAYED  1 ) ] 
lz>  (*  (SUIT-OF  (CARDS-PLAYED1  PI))  (SUIT-LED)) 

(NOT  (HIGHER  ( CARDS- PLAYE D 1  PI) 

(CAROS-PLAYED1  ME)))])]) 

(O  (HAS  PO  X2 )  [EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  X2)]) 

9:32  ---  [by  RULE329]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  [O  (HAS  ?0  X2)  (HAS  PI  X2)]) 

(CAUSE  [EXISTS  PI  (OPPONENTS  ME)  (HA£  PI  XI)]) 

10:6  ---  [by  RULE329 ]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  [CAUSE  (HAS  PI  XI)]) 

(UNDO  [EXISTS  P3  (OPPONENTS  ME)  (HA£  p3  XI)]) 

10:27  ---  [by  RULE329 ]  ---> 

(EXISTS  P3  (OPPONENTS  ME)  [UNDO  (HAS  P3  XI)]) 
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(CAUSE  [EXISTS  Cl  (CARDS)  (Mfi  [HAS  P0  Cl]  [IN-SUIT  Cl  SO])]) 
12:6  ---  [by  RULE329]  ---> 

(EXISTS  Cl  (CARDS)  [CAUSE  (AND  [HAS  P0  Cl]  [IN-SUIT  Cl  SO])]) 


RULF.359:  (and  [until  P  A] ...)  ->  (until  P  (and  A  ...))  --  extract  UNTIL 

(ANO  [UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS)))]) 

5:3  ---  [by  RULE359]  ---> 

(UNTIL  (PLAYED!  QS) 

(AND  [ACHIEVE  (LEAD-SPADE  ME)] 

[ACHIEVE  (NOT  (OURING  (TRICK)  (TAKE  ME  QS)))])) 

RULE360:  (and  [achieve  P 1  ] ...  [achieve  PJ)  ->  (achieve  (and  P,  ...  Pn))  --  collect  ACHIEVE 

(ANO  [ACHIEVE  (LEAD-SPADE  ME)] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS)))]) 

5:4  ---  [COLLECT  by  RULE360]  —> 

(ACHIEVE  (AND  [LEAD-SPADE  ME] 

[NOT  (DURING  (TRICK)  (TAKE  ME  QS))])) 


5.10.2.  Transfer 


Another  kind  of  restructuring  transformation  transfers  information  from  one  component  of  an 
expression  to  another  at  the  same  level,  Le..  from  e  to  e.  in  (fCj  ...  en).  One  such  rule  is 

RULE161:  (Q  x  S  P[fx))  ->  (Q  y  [project  f  S]  Py) 


It  introduces  a  change  of  variable  from  player  Pi  to  location  Yl  by  transferring  f  from  P  to  S: 
(OUT  QS) 

4:2-4  ---  [ELABORATE  by  RULE  124]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  ( =  (LOC  QS )  [HAND  PI])) 

4:5  ---  [TRANSFER  by  RULE161]  ---> 

(EXISTS  Yl  [PROJECT  HAND  (0PP0NEN1S  ME)]  (=  (LOC  QS)  Yl)) 

4:6  ---  [RECOGNIZE  by  RULE  162]  ---> 

(IN  (LOC  QS)  [PROJECT  HAND  (OPPONENTS  ME)]) 

4:7  ---  [PIGEON-HOLE  by  RULE  169]  ---> 

( NOT 

(IN  (LOC  QS)  [DIFF  (RANGE  LOC)  (PROJECT  HAND  (OPPONENTS  ME))])) 


lhc  requantified  equality  is  recognized  as  set  membership,  allowing  tire  pigeon-hole 
principle  (§2.2)  to  be  applied.  Note  dial  the  transfer  introduces  PROJECT  as  a  syntactic  side  effect. 


r  oo's  other  transfer  ailcs  are  listed  below  with  examples  of  their  use. 

RULED:  (Q  x  [M  y  S  e .]  P  )  ->  (Q  y  S  P  ),  where  M  is  injective  -  change  of  variable 

1  *  V 


I 
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(FORALL  INTERVAL1  [DISTRIBUTE  14  ( LB ; UB  2  (#  PR0JECT1) 

( INTERVAL  ( PROJECT  1  (-  14  1))  (PR0JECT1  14))] 

( USABLE  -  INTERVAL !  INTERVAL  1 ) ) 

13:30  ---  [REMOVE-QUANT  by  RULE13]  ---> 

(FORALl  14  ( LB : UB  2  {#  PROJECT1)) 

(USABLE-INTERVAL!  (INTERVAL  (PROJECT1  (-  14  1))  (PROJECT1  14)))) 

RL'l  HIS-’ :  (union  ...  [set  ej  ...  ej  ...  [set  ek-r  l  ...  enl ...)  ->  (union  [set  cl  ...  ej  ...) 

(UNION  [PILES  (PLAYERS)]  [SET  DECK  POT  HOLE]  [SET  (HAND  ME)]) 

4:29  ---  [SIMPLIFY  by  RULE  18  7]  ---> 

(UNION  [SET  DECK  POT  HOLE  (HAND  ME)]  [PILES  (PLAYERS)]) 

RL'L  (forall  x  [set-of  v  S  P  ]  Rx)  ->  (forall  x  S  [  =  >  ?x  RJ) 

( FCRALL  XI  [SET-OF  C 19  CARDS - P LAYED 1  (  =  (SUIT-OF  C 13 )  (SUIT-LED))] 
(NOT  (HIGHER  XI  ( CAROS - PLAYEO 1  ME)))) 

2:79  ---  [by  RULE219]  ---> 

(FORALL  XI  CARDS-PLAYED 1 

[*>  (  =  (SUIT-OF  XI)  (SUIT-LEO)) 

(NOT  (HIGHER  XI  (CARDS-PLAYED1  ME)))]) 

RLl.F.'Zb:  (in  [S  i]  S)  ->  (in  i  [indiccs-of  S)) 

(IN  ( C ARDS  -  PL AYEO 1  ME)  CARDS  -  PLAYED  1 ) 

2:69  ---  [REDUCE  by  RULE326]  ---> 

(IN  ME  (INDICES-OF  CAROS -PLAYED  1 )  ) 

RLI.F32S:  (Q  x  S  P  )  ->(Q  i  [indiees-of  S]  P,_  ,)  -  change  of  variable 

X  1J  * 

(FORALL  XI  CARDS-PLAYED1 

(=>  (=  (SUIT-OF  XI)  (SUIT-LED)) 

(MOT  (HIGHER  XI  (CARDS-PLAYED1  ME))))) 

2:80  ---  [by  RULE328 ]  ---> 

(FORALL  PI  [TNOICES-OF  CARDS - PLAYEO  1  ] 

(  =  >  ( --  (SUIT-OF  [CARDS-PLAYED  1  PI])  (SUIT-LED)) 

(NOT  (HIGHER  [CARDS-PLAYEDI  PI]  ( CARDS-PLAYED1  ME))))) 

(FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAXI))) 

13:73  ---  [by  RULE328 ]  ---> 

(FORALL  15  [INDICES-OF  PROJECT1] 

(NOT  (HIGHER  [PROJECTl  15]  CLIMAXI))) 


RULF330:  (forall  i  [indiees-of  S)  [...  (in  c  [indiees-of  S]) ...])  -> 

(forall  i  [indiccs-of  S]  [...  (not  (after  e  i)) ...]), 

where  e  is  an  element  of  a  sequence  suiting  with  (indiccs-of  S) 
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(FORALL  PI  [INOICES-OF  CARDS  -  PLAYED  1 ] 

[  =  >  i  IM  ME  flNDICES-OF  CARDS  -  PL AY  EDI  1 1 
(AND  [IN  (CARDS-PLAYED1  ME) 

(CARDS- IN -SUIT -LED  CARDS-PLAYED1 ) ] 

[=>  (=  (SUII-OF  ( CARDS-  PLAYED1  PI))  (SUIT-LED)) 
(NO.  (HIGHER  ( CARDS- PLAYED1  PI) 

(CAROS-PLAYED1  ME)))])]) 

2:82  ---  [by  RULE330]  ---> 

(FORALL  PI  [INDICES-OF  CARDS  -  PLAYED  1 ] 

[  =  >  (NOT  (AFTER  ME  Pin 

(AMD  [IN  (CARDS-PLAYED1  ME) 

(CARDS- IM-SUIT -LED  CARDS  -  PL A YED 1 ) ] 

[=>  (=  (5UIT-OF  ( CARDS-PLAYED1  PI))  (SUIT-LED)) 
(NOT  (HIGHER  (CARDS-PLAYED1  PI) 

(CARDS-PLAYED1  ME)))])]) 


5.10.3.  Functions  as  Functionals 

In  FOO's  l. ISP-like  representation,  the  arguments  of  an  expression  (f  e1  ...  en)  may  be  functions, 
and  the  value  of  the  expression  may  be  a  function.  Such  a  mapping  f  from  functions  to  functions  is 
called  Afunctional.  Functions  are  sometimes  treated  as  functionals  and  vice  versa.  For  example,  tire 
same  boolean  operator  and  is  used  both  as  a  function  on  truth  values  and  as  a  functional  on 
predicates,  under  the  obvious  definition: 

(and  [lambda  (x)  PJ  [lambda  (y)  R  ])  =  (lambda  (x)  (and  Px  R^)) 

The  advantage  of  treating  functions  and  functionals  interchangeably  is  increased  generality:  both 
can  be  manipulated  by  the  same  rules.  F.ssentially.  operators  like  and  arc  treated  as  generic  operators , 
and  knowledge  about  them  is  encoded  once,  under  the  generic  form,  rather  than  separately  for  each 
variant  corresponding  to  different  argument  types.  Moreover,  this  somewhat  ambiguous  usage  saves 
steps.  P'or  example,  propositions  (representing  boolean  values)  can  be  conjoined  directly  with 
predicates  (functions  onto  boolean  values)  in  a  mixed  notation,  allowing  expressions  like 
(and  [=  e1  e,]  [lambda  (x)  PJ).  The  alternative  would  require  longer  expressions,  and  presumably 
more  steps  to  construct  and  manipulate  them. 

A  function  f  in  an  expression  (f  ...  [g  Cj  ...  ej  ...)  can  be  functionalized,  i.e..  converted  into  a 

functional  on  g,  by  rcstaicturing  the  expression  as  ([f ...  g  ...]  Cj  ...  cn).  as  illustrated  in  DKRIV14: 

(OR  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-t)] 

[=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

14:48  -  [functionalize  OR  by  RULE297]  — > 

([OR  HIGHER  =]  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 
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(NOT  [(OR  HIGHER  =)  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

14:49 - [f  unctional  l  ze  NOT  by  RULE298] - > 

([NOT  (OR  HIGHER  =  )]  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(NOT  (OR  HIGHER  =)) 

14:50  ---  [RECOGNIZE  by  RULE299 ]  ---> 

LOWER 


Here  Lhe  functions  OR  and  NOT  are  functionalized  respectively  by 

RLI  E297:  ( R  [P  e,j  [P‘  e,  e,])  ->  <[R  P  P’J  e,)  --  functionalize  boolean  operator  R 
RL’LE29$:  (not  [P  ...])  ->  ([not  P| ...)  ••functionalize  NOT 


This  makes  it  possible  to  merge  two  eases  in  terms  of  a  single  predicate: 

(NOT  (OR  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)] 

[=  (NEXT  NOTE)  (CLIMAX  CANTUS-1)])) 

14:48-50  —  [functionalize  and  recognize]  - > 

(LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-- 1 ) ) 


1'his  kind  of  transformation  is  useful  in  dealing  with  fluents  --  entities  that  change  over  time  - 
represented  in  ECO  as  unary  functions.  Two  other  rules  for  fluents  are  illustrated  below: 


RUI.E305:  (g  (ft))  ->  ([g  t]  t),  where  f is  a  fluent  --  functionalize g 
(NEXT  (NOTE  T 1 )  ) 

14:34  ---  [functionalize  MOTE  by  RULE305]  ---> 

{[NEXT  NOTE]  Tl) 

RULE393:  (lambda  (t)  [g  ...  (f ...  t ...) ...])  ->  (g  ...  [lambda  (t)  If...  t  ...)1 ...)  -  functionalize  g 
(LAMBDA  (J) 

[APPEND  (PREFIX  CANTUS  J)  (LIST  (NTH  CANTUS  j*  J  1 ) )  )  D 
14:13  ---  [functionalize  APPEND  by  RULE393]  ---> 

(APPEND  [LAMBDA  (J)  (PREFIX  CANTUS  Jj] 

[LAMBDA  (J)  (LIST  (NTH  CANTUS  (+  J  1)1)1) 

(LAMBDA  (J)  [LIST  (NOTE  j±  J  1)11) 

14:16  -  [functionalize  LIST  by  RULE393]  - > 

(LIST  [LAMBDA  (J)  (NOTE  (-  J  HI]) 


The  inverse  transformation  Jcfuncuonaiizes a  functional  on  fbv  applying  f  to  an  argument: 
RLT.E273:  ([g  ...  f ...]  t)  ->  (g  ...  [ft] ...),  for  every  fluent  fin  (g  ...)  --  defunctionalize  g 


This  is  illustrated  in  DERIV14: 
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([OR  [AMO  [=  (^OCCURRENCES  (CLIMAX  CANTUS-t)  CANTUS-1I  1] 

[LOWER  (NEXT  MCI  El  (CLIMAX  CANTUS-l))] 

[HIGHER  (NEXT  NOTE )  (CLIMAX  CANTUS-IF)! 

Tl) 

14:82  ---  [defunctional  ize  OR  by  RULE273 ]  ---> 

(OR  [AND  [=  ( ^OCCURRENCES  (CLIMAX  [CANTUS- 1  TIT)  fCANTUS-f  Til)  1] 
[LOWER  (NEXT  [NOTE  Till  (CLIMAX  fCANTUS-1  IU)]j 
[HIGHER  (NEXT  (NOTE  T 1  ~]  T  (CLIMAX  fCANTUS-1  111111 


5.10.4.  Restructuring:  Summary 

Restructuring  transformations  help  put  an  expression  ( f  e1  ...  e  )  in  the  syntactic  form  required  by  a 
given  operationalization  or  analysis  mctliod.  They  fall  into  three  classes: 

1.  Function  transposition  exchanges  f  with  a  function  g  occurring  in  e;. 

a.  Distribution,  illustrated  by  some  rules  for  propagating  splits,  generates  more  than  one 
copy  of  f. 

b.  Collection,  used  in  merging  cases,  combines  multiple  copies  of  g  into  one. 

c.  Transposing  a  single  instance  of  f  with  a  single  instance  of  g  embeds  f  and  extracts  g.  and 
helps  apply  one  concept  to  another  by  removing  an  intervening  function. 

2.  Transfer  moves  information  from  an  argument  ej  to  another  argument  e.. 

a.  A  change  of  variable  can  be  introduced  in  a  quantified  expression  (Q  x  S  P  )  by 
transferring  information  between  S  and  P. 

3.  Functionals  ••  functions  from  functions  to  functions  --  can  represent  entities  that  depend  on 
jluents(fi\ notions  of  time). 

a.  Moving  information  between  f  and  ef  functionalizes  f --  converts  it  into  a  function  --  by 
changing  a  subexpression  (g  ...)  of  e.  to  j  function  g. 

b.  Conversely,  changing  die  function  g  to  an  expression  (g  ...)  defunctiondiees  the  functional 
f. 

'I his  section  discusses  restructuring  as  a  syntactic  problem-solving  tactic,  since  that  is  its  purpose  in 
POO.  Alternatively,  one  could  classify  a  restructuring  transformation  in  terms  of  its  effect  on  the 
semantics  of  the  expression  to  which  it's  applied.  This  viewpoint  involves  some  mathematical 
concepts  of  invariance.  For  example,  distribution  and  collection  preserve  semantic  equivalence  when 
die  appropriate  distributive  law  holds,  and  a  transposition  (f  (g  e))  ->  (g  (f  e))  preserves  equivalence  if 
the  operators  f  and  g  commute.  Many  of  FOO's  restructuring  transformations  do  not  always  preserve 
equivalence,  and  it  can  be  far  from  straightforward  to  characterize  concisely  the  class  of  expressions 
to  which  a  given  restructuring  rule  can  be  applied  without  a  change  of  meaning.  However,  such  rules 
arc  useful  as  heuristic  transformations  when  they  give  empirically  valid  results. 
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5.11.  Knowledge  Used  in  Analysis 

In  (§5.1),  FOO’s  analysis  methods  are  classified  based  on  how  they  are  used.  Alternatively,  the  rules 
could  be  classified  according  to  the  knowledge  they  arc  based  on;  for  instance,  rules  about  sets  could 
be  discussed  as  a  group.  However,  such  an  organization  would  reveal  little  about  how  the  rules  are 
used.  Other  criteria  that  might  be  used  to  classify  analysis  methods  include: 

1.  Kinds  of  knowledge  needed  to  apply  the  method 

a.  Syntactic  knowledge 

Used  to  match  ailes  against  expressions  (§B.3) 

b.  Conceptual  knowledge  (§1.3) 

Semantic  network  used  in  intersection  search  (§5.6) 

Concept  definitions  used  in  elaboration  and  recognition  (§1.3.1) 

Is-a  hierarchy  used  in  matching  rules  (§6.1) 

Relations  like  OPPOSITE-OF  used  in  rephrasing  (§6.1.4) 

Homomorphisms  used  in  function  transposition  (§6.1.2) 

c.  Procedural  knowledge 

Search  algorithm  used  in  intersection  search  (§5.6) 

Procedures  used  in  systematic  evaluation  (§5.2.2) 

d.  Logical  knowledge  (§5) 

Analysis  required  to  test  for  special  case  (§5.9.1) 

2.  Semantic  relationship  between  e  and  e'  in  transformation  e  ->  e’ 

a.  Equivalence  (valid  rules)  --  e  =  e’ 

Special-case  reduction  (§5.9.1) 

Check  sufficient  condition  (§5.9. 1.1) 

Check  necessary  condition  (§5.9. 1.2) 

Heuristic  equivalence-preserving  reduction  (§5.9.2. 1) 

Simplification  (§5.2) 

Translation  (§5,8) 

b.  Su/ftcient  condition  (sound  rules)  —  e’  =  >  e  (§5.9.2. 2) 
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Relevant  implication  (§5. 9. 2.2.1) 

Partial  matching  (§5.3.3) 

Try  example  (§5.4.4) 

Restrict  form  of  variable  (§5.4.2) 

c.  Necessary  condition  -•  e  =>  e'  (§5.9 .2.3) 

Solve  equality  for  value  of  variable  (§5.4.1) 

d.  Non-equivalence  --  e  *  e‘  (§5.9.2.4) 

Defer  time  frame  for  achieving  goal  (§5.9.2.4) 

However,  these  criteria  distinguish  rather  superficially  (§5.9.3)  between  analysis  performed  in 
testing  a  rule  condition  (§5.9.1)  and  analysis  performed  after  the  rule  is  applied  (§5.9.2).  For 
example,  consider  two  rules: 

1.  e  •>  T  if  C  -  preserves  equivalence;  verifying  the  condition  C  requires  analysis  (§5.9. 1.1) 

2.  e  ->  C  -  transforms  e  into  a  sufficient  condition  C  without  analysis (§5.9.22) 

These  rules  are  almost  identical,  but  would  be  classified  differently  with  respect  to  the  semantic 
relationship  between  left-  and  right-hand  sides:  the  first  rule  is  valid,  while  the  second  is  merely 
sound.  Moreover,  the  distinction  breaks  down  in  practice  since  roo  has  mechanisms  (§5. 9.3.2)  for 
treating  the  first  rule  as  if  it  were  the  second  by  reducing  C  to  an  assumption  (§5.9.3. 1), 
restriction  (§5.9.3.2.2),  or  subgoal  (§5.9.3.2.1)(§5.9.3.2.J). 

The  next  chapter  examines  in  greater  depth  the  ways  in  which  different  forms  of  conceptual 
knowledge  arc  used  in  (00. 
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Chapter  6 

Applications  of  Conceptual  Knowledge 

Previous  chapters  have  described  lOO's  knowledge  of  methods  for  operationalization  (§2)  (§3), 
reformulation  (§4).  and  analysis  (§5).  Ihcsc  methods  draw  on  knowledge  of  concepts ,  both  domain- 
specific  concepts  like  TRICK,  and  general  concepts  like  HOMOMORPHISM.  The  various  representations 
used  to  encode  such  conceptual  knowledge  in  srOO  were  described  earlier  (§1.3)  and  arc  illustrated 
below: 

1.  Concept  definitions,  e.g.. 

TAKE -POINTS  =  (LAMBDA  (P)  [FOR-SOME  C  ( POINT -CARDS )  (TAKE  P  C)]) 

2.  Connections  in  an  is-a  hierarchy,  e.g., 

TRICK  is-a  ACTION 

3.  Semantic  relations,  e.g.. 

OPPOSITE  of  HIGH  is  LOW 

4.  Domatn-spccific  "fact"  rules,  e.g., 

RULE376:  ( »  (cards-in-suit  s»  ->  13 

This  chapter  discusses  the  various  ways  such  knowledge  is  used  in  the  derivations: 

1.  Match  a  general  rule  to  a  specific  concept  (§6.1). 

2.  F.xpand  the  definition  of  a  domain  concept  (§6.2). 

3.  Recognize  an  expression  as  a  familiar  concept  (§6.3). 

4.  Apply  a  rule  that  exploits  a  know  n  or  assumed  property  of  the  task  domain  (§6.4). 

5.  Find  a  domain  concept  satisfying  a  given  test  (§6.5). 

(§6.6)  discusses  additional  knowledge,  missing  in  1 00.  about  the  semantic  appropriateness  (validity 
and  soundness)  of  applying  various  transformation  rules.  Finally.  (§6.7)  summarizes  the  ways 
conceptual  knowledge  is  represented  and  used  in  t  oo. 
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6.1.  Matching  General  Rules 

The  semantic  relations  encoded  in  POO  (§1.3.2)  arc  primarily  used  to  make  contact  between 
general  concepts  used  in  rules  and  more  specific  concepts  used  to  express  and  reason  about  advice. 
For  example,  the  general  concept  of  reflexive  relations  is  used  in  a  rule  for  partial  matching  (§5.3): 

RULE43:  (R  [f  e,  ...  e  ]  [f  e.’ ...  e  ’])  ->  (and  [=  c.  e ’] ...  [=  c  e  ']),  where  R  is  reflexive 

1  1  nJ  1  1  n  1  1  1  1 1  1  n  n 1 

In  DERIV5,  this  rule  is  applied  w  ith  R  =  OUR  IMG: 

(DURING  [TAKE  { TRICK -WINNER )  Cl]  [T AXE  ME  QS]) 

5:12  ---  [REOUCE  by  RULE43]  ---> 

(AND  [=  (TRICK-WINNER)  ME]  [=  Cl  QS]) 

This  transformation  is  justified  ( i.e .,  logically  sound)  because  DURING  is-a  REFLEXIVE.  The 

same  rule  applies  to  other  relations  as  well,  e.g.,  =>  and  =: 

(O  [MOVE  C4  (HAND  PI)  POT]  [MOVE  C3  (HAND  { QSO ) )  L0C3]) 

3:52  ---  [REDUCE  by  RULE43]  ---> 

(AND  [*  C4  C3]  [  =  (HAND  PI)  (HAND  (QSO))]  [=  POT  L0C3]) 

[=  (HAND  PI)  (HANO  (QSO))] 

3:55  ---  [REOUCE  by  RULE43]  ---> 

(AND  [«  PI  (QSO)]) 

POO's  rule  matcher  searches  the  is-a  hierarchy  to  determine  whether  a  component  of  an  expression 
matches  the  corresponding  component  of  a  rule.  It  matches  the  expressions  above  by  finding  the 
direct  connection  =>  is-a  reflexive  and  the  path  =  is-a  EQUIVALENCE  is-a  REFLEXIVE. 

FOO  also  uses  stored  semantic  relations  to: 

Recognize  instances  of  specialized  concepts  used  in  rules  (§6.1.1). 

Exploit  homomorphic  relationships  (§6.1.2). 

Simplify  expressions  involving  identity  elements  (§6.1.3). 

Find  connections  between  related  adjectives  (§6.1.4). 

6.1.1.  Recognizing  Special  Cases 

The  is-a  hierarchy  can  be  used  to  detect  special  cases.  For  example,  in  DERIV13  a  reduction  is 

made  based  on  the  knowledge  that  ( ^OCCURRENCES  . . . )  must  be  non-negative: 

(*<  (^OCCURRENCES  CLIMAX1  PR0JECT1)  0) 

13:111  ---  [RECOGNIZE  by  RULE392]  ---> 

(*  (^OCCURRENCES  CLIMAX1  PROJECTl)  0) 
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This  transformation  is  made  by 

RULE392:  (  =  <e0)->(  =  e  0)  if  e  is  non-negative 

To  infer  that  (^OCCURRENCES  . .  . )  is  non-negative,  TOO  first  retrieves  the  definition 
^OCCURRENCES  =  (LAM8DA  (N  C)  {»  (SET-OF  X  C  (=  X  N) ) ) ) 

FOO  then  finds  the  path  #  is-a  NON-NEGATIVE-INTEGER  is-a  NON-NEGATIVE.  This  justifies 
applying  RULE392,  which  is  only  valid  in  the  special  case  where  e  is  non-negative. 


6.1.2.  Exploiting  Homomorphisms 


Semantic  relations  other  titan  “is-a"  are  also  used  in  applying  general  rules  to  specific  concepts. 
One  such  rule  encodes  knowledge  about  homomorphisms: 

RULF.2S4:  (f ...  [g  e: ...  ej  ...)  ->  (g  [f ...  et ...] ...  [f ...  en  ...1), 

where  (lambda  (x)  (f ...  x  ...))  is  a  homomorphism,  and  g  and  g'  correspond  to  +  and  + '  in  the 
homomorphism  condition  fix  +  y)  =  fix)  +'  fiy) 


To  apply  RULE284  to  an  expression  (f ...)  where  f  is-a  homomorphism,  roo  uses  the  stored 

relation  ADD  of  f  is  g\  Each  example  below  is  preceded  by  the  relation  used. 

ADO  of  CHOICE-SEQ-OF  is  APPEND  (g  is  SCENARIO) 

( CHOICE -SEQ-OF  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))]) 

2:6  ---  [by  RULE284]  ---> 

(APPEND  [CHOICE -SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))] 

[CHOICE-SEQ-OF  (TAKE-TRICK  ( TRICK-WINNER) ) ] ) 

ADD  of  HAVE-POINTS  is  OR  (g  is  APPEND) 

(HAVE-POINTS  [APPEND  CAROS -PLAYED I  (LIST  C2 I )  ] ) 

2:102  ---  [DISTRIBUTE  by  RULE2S4]  ---> 

(OR  [HAVE-POINTS  CARDS -PLAYED1 ]  [HAVE-POINTS  (LIST  C21)j) 

AOO  of  IN  is  OR  (g  is  UNION) 

(IN  (LOC  QS) 

[UNION  (SET  OECK  POT  HOLE  (HAND  ME))  (PILES  (PLAYERS))]) 

4:31  ---  [DISTRIBUTE  by  RULE284]  ---> 

(OR  [IN  (LOC  QS)  (SET  DECK  POT  HOLE  (HAND  ME))] 

[IN  (LOC  QS)  (PILES  (PLAYERS))]) 


AOO  of  DURING  is  OR  (g  is  SCENARIO) 
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(DURING  [SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI) 

(TAKE-TRICK  ( TRICK-WINNER) )] 

(TAKE-POINTS  ME)) 

6:4  ---  [DISTRIBUTE  by  RULE2S4]  ---> 

(OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)] 
[DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE-POINTS  ME)]) 

ADD  of  ^OCCURRENCES  is  +  (g  is  APPENO) 

(^OCCURRENCES  CLIMAX1  [APPENO  PROJECT1  (LIST  NOTE 3  )  ] ) 

13:106  ---  [DISTRIBUTE  by  RULE284]  ---> 

(+  [^OCCURRENCES  CLIMAX1  PROJECT1] 

[^OCCURRENCES  CLIMAX1  (LIST  NOTE3 ) ] ) 


6.1.3.  Identity  Elements 

Two  general  simplification  rules  about  identity  elements  of  additive  operators  are  applied  to  a 
variety  of  expressions  based  on  the  stored  relation  IDENTITY  of  C  is  i: 

RULK341:  (C  i  e)  ->  e,  where  C  is  a  commutative  operator  and  i  is  its  identity  element 

RU1.E343:  (C  e  i)  ->  e,  where  C  is  a  commutative  operator  and  i  is  its  identity  element 

A  few  of  the  many  expressions  simplified  by  these  rules  arc  shown  below,  preceded  by  the  relevant 
relations: 

IDENTITY  of  AND  is  T 

3:19  (AND  T  [LEGAL  (QSO)  QS])  — >  (LEGAL  (QSO)  OS) 

IDENTITY  of  OR  is  NIL 

5:9  (OR  NIL  [DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE  ME  QS)]) 

IDENTITY  of  D*  is  INCREASING 

9:48  (D*  INCREASING  [DEPENDENCE  { PR-OISJOINT - FORMULA  #H  #S  #U)  #S]) 
IDENTITY  of  D+  is  NIL 

9:53  (D+  [DEPENDENCE  (0CHOOSE  (-  #U  #S)  #H)  0S]  NIL) 

IDENTITY  of  +  is  0 

14:26  (+  [^OCCURENCES  (CLIMAX  CANTUS-1)  CANTUS-1]  0) 
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FOO's  semantic  relations  are  also  used  to  relate  different  forms  of  adjectives.  For  instance,  the 
adjective  LOW,  a  unary  predicate,  has  LOWER  as  its  comparative  form,  LOWEST  as  its  superlative,  and 
HIGH  as  its  opposite.  These  relations  are  exploited  using  die  rules  listed  below  with  examples  of  their 
use  and  the  relations  involved. 

RULH153:  (R  eT  e.,)  ->  (R’  e1  c,),  where  OPPOSITE  of  R  is  R’ 

OPPOSITE  of  HIGHER  is  LOWER 

(HIGHER  XI  (CARO-OF  ME)} 

7:5  ---  [by  RULE  155 ]  ---> 

(LOWER  (CARD-OF  ME)  XI) 

OPPOSITE  of  >=  is  =< 

(>=  1  (^OCCURRENCES  CLIMAX1  PROJECT1)) 

13:87  ---  [by  RULE153]  ---> 

(=<  ( ^OCCURRENCES  CLIMAX1  PR0JECT1)  1) 

RULE154:  (R  ex)  ->(Pe),  where  PREDICATE  of  R  is  P 

PREOICATE  of  LOWER  is  LOW 

(LOWER  (CARD-OF  ME)  XI) 

7:6  ---  [REDUCE  by  RULE  154]  ---> 

(LOW  (CARD-OF  ME)) 


RULF.277:  (change  (fS»  •>  (R  [f  (change  S)]  (f  S]).  where  COMPARATIVE  of  f  is  R 

COMPARATIVE  of  HIGHEST  is  HIGHER 

(CHANGE  (HIGHEST  CANTUS-1)) 

14:42  ---  [REDUCE  by  RULE277]  ---> 

(HIGHER  [HIGHEST  (CHANGE  CANTUS-1)]  [HIGHEST  CANTUS-1]) 

RUI.H300:  (next  (f  S))  ->  (f  (change  S))  if  (R  [f  (change  S)]  [f  SJ), 
where  COMPARATIVE  of  f  is  R 

COMPARATIVE  of  HIGHEST  is  HIGHER 

(NEXT  (HIGHEST  CANTUS-1)) 

14:55-57  ---  [REOUCE  by  RULE300 ,  analysis]  ---> 

(HIGHEST  (CHANGE  CANTUS-1)) 

Since  (HIGHER  [HIGHEST  (CHANGE  CANTUS-1)]  [HIGHEST  CANTUS-1]) 


RUI.E304:  (in  c  S)  ->  nil  if  (R  e  [f  Sj). 

where  R  is  some  ordering  and  SUPERLATIVE  of  R  is  f 

SUPERLATIVE  of  HIGHER  is  HIGHEST 
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(IN  (NEXT  NOTE)  CANTUS-1) 

14:72-76  [REDUCE  by  RULE304 ,  analysis]  ---> 

NIL 

since  (HIGHER  [NEXT  NOTE]  [HIGHEST  CANTUS-1]) 

RULE367:  (not(P  e)) ->  (P’ e),  where  OPPOSITE  of  P  is  P’ 

OPPOSITE  of  LOW  is  HIGH 

(NOT  (LOW  (CARD-OF  ME))) 

7:8  ---  [by  RULE367]  ---> 

(HIGH  (CARO-OF  ME)) 

6.2.  Expanding  Concept  Definitions 

Expanding  the  definition  of  a  concept  helps  bring  detailed  lower-level  (general)  knowledge  about 
it  to  bear  on  the  problem  at  hand.  Such  elaboration  (§5.8.2)  can  help  map  a  problem  to  a  known 
method.  In  DERIV9,  expanding  the  definition  of  VOID  produces  a  predicate  on  the  uncvaluable  set 
(CARDS- IN-hand  P0)  and  suggests  using  the  disjoint  subsets  method  (§2.3): 

(VOID  P0  SO) 

9:1  ---  [ELABORATE  by  RULE124]  ---> 

(NOT  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO))) 

9:2-26  ---  [by  RULE  189 ,  analysis]  ---> 

(PR-DISJOINT  (CARD-IN-HAND  PO)  (CARDS- IN-SUIT  SO)  (CARDS)) 

If  a  concept  is  defined  in  terms  of  an  aggregate  of  components,  such  as  a  conjunction,  disjunction, 
or  sequence,  plugging  its  definition  into  a  problem  may  help  split  it  into  separately  solvable 
subproblcms.  This  use  of  elaboration  is  discussed  at  length  elsewhere  (§5.7  .4). 

6.3.  Recognizing  Concept  Definitions 

Recognizing  an  expression  as  an  instance  of  a  defined  concept  (§5.8.3)  can  also  help  map  the 
expression  to  a  known  method,  either  a  rule  or  a  previously  generated  operationalization  (§6.3.1).  In 
simple  cases,  recognition  can  be  performed  by  substituting  a  concept  name  for  a  sub-expression  in 
the  problem:  this  corresponds  to  the  folding  transformation  in  [Darlington  76J.  More  complicated 
cases  involve  solving  a  reformulation  equation  (§4)  for  an  appropriate  function  (§6.3.2). 

An  example  of  recognition  occurs  in  DERIV12,  where  an  intersection  search  rule  is  used  to  show 
that  voids  can't  be  undone: 

RU1.F57:  (during  s  e)  ->  nil  if  no  sub-events  of  s  arc  abstractions  of  e 
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To  use  the  rule,  e  must  be  expressed  in  terms  of  a  known  action  concept  more  specific  than  MOVE. 

t  his  is  accomplished  by  recognizing  (UNDO  (VOID  PO  SO) )  m  terms  of  GET-CARO: 

I  (OURING  (ROUND- IN- PROGRESS) 

(UNDO  (VOID  PO  SO))) 

12:2-9  —  [by  analysis]  — > 

(DURING  (ROUNO- IN- PROGRESS) 

(EXISTS  Cl  (CARDS)  (AND  [MOVE  Cl  LOCI  (HAND  PO)] 

[IN-SUIT  Cl  SO]))) 

.  12:10  ---  [RECOGNIZE  by  RULE123]  ---> 

T  (DURING  (ROUND-IN-PROGRESS) 

(EXISTS  Cl  (CAROS)  (AND  [GET-CARD  PO  Cl  LOCI] 

[IN-SUIT  Cl  SO]))) 

12:11  ---  [COMPUTE  by  RULE57]  ---> 

NIL 


Similarly,  recognition  can  help  reformulate  an  expression  in  terms  of  an  executable  action.  In 

DERIV8,  an  abstract  plan  for  getting  void  in  a  suit  is  made  concrete  by  recognizing  play: 

(ACHIEVE  (VOID  ME  SO)) 

8:1-10  -  [by  RULES,  analysis]  > 

(UNTIL  (VOID  ME  SO) 

(ACHIEVE  (AND  [MOVE  Cl  (HAND  ME)  LOCI]  [IN-SUIT  Cl  SO]))) 

8:11  ---  [RECOGNIZE  by  RULE123]  ---> 

(UNTIL  (VOID  ME  SO) 

(ACHIEVE  (AND  [PLAY  ME  Cl]  [IN-SUIT  Cl  SO]))) 

8:13  ---  [RECOGNIZE  by  RULE  123]  ---> 

(UNTIL  (VOIO  ME  SO) 

(ACHIEVE  (PLAY-SUIT  ME  SO))) 


The  concept  PLAY-SUIT  is  recognized  simply  for  convenience,  to  shorten  die  solution;  this  doesn't 
make  the  plan  any  more  operational.  A  caveat  to  this  statement  has  to  do  with  a  bit  of  lazy  notation 
1  used  in  the  derivation.  The  lack  of  an  explicit  existential  quantifier  for  the  variable  Cl  comes  from 

using 


RUL.H7:  (remove-l-from  (set-of  x  S  P^))  ->  (undo  (and  [in  x  S]  P^l) 

(REM0VE-1-FR0M  (SET-OF  Cl  (CARDS- IN-HAND  ME)  (IN-SUIT  Cl  SO))) 
8:4  ---  [REOUCE  by  RULE7]  ---> 

(UNDO  (AND  [IN  Cl  (CAROS- IN-HAND  ME)]  [IN-SUIT  Cl  SO])) 


The  alternative  is  to  use  the  more  precise 


§  RUI.H7a:  (remove- 1- from  (set-of  x  S  P^))  ->  (for-some  x  S  (undo  (and  [in  x  S]  Pj)) 

( REMOVE- 1  -  FROM  (SET-OF  Cl  (CARDS- IN-HAND  ME)  (IN-SUIT  Cl  SO))) 
8:4'  ---  [REOUCE  by  RULE7a]  ---> 

(FOR-SOME  Cl  ( CAROS  - IN-HANO  ME) 

(UNDO  (AND  [IN  Cl  ( CARDS- IN-HAND  ME)]  [IN-SUIT  Cl  SO]))) 


» 


This  wuutd  produce  the  expression 


I 
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(F0R-S0ME  Cl  ( CAROS- IN-HAND  ME) 

(AND  [PLAY  ME  Cl]  [IN-SUIT  Cl  SO])) 

This  expression  is  executable  given  the  ability  to  scan  through  (CARDS- IN-HAND  ME),  test  the  suit 
of  each  card,  choose  one  in  suit  SO,  and  play  it.  Moreover,  it  would  match  a  proper  definition  of 
PLAY-SUIT,  as  opposed  to  the  ad  hoc  one  used  above,  with  its  implicitly  quantified  variable  ?C: 

PLAY-SUIT  =  (LAMBOA  (P  S)  (AND  [PLAY  ME  ?C]  [IN-SUIT  ?C  S])) 

The  point  is  that  the  inclusion  of  PLAY-SUIT  in  the  knowledge  base  was  not  necessary  for  deriving 
an  operational  solution  to  this  problem:  it  was  only  included  to  provide  a  convenient  name  for  a 
derived  concept. 

6.3.1.  Recognition  and  Learning 

In  the  examples  above,  recognition  was  used  to  map  problems  onto  general  methods 
(transformation  rules)  or  runtime  capabilities  (executable  actions  and  permissible  observations). 
Recognition  could  also  be  used  to  map  problems  onto  previously  derived  operationalizations.  For 
example,  suppose  the  concept  TRICK-HAS-POINTS  has  been  operationalized  by  deriving  methods  for 
predicting  whether  a  trick  will  have  points.  These  methods  could  be  retrieved  when  a  subsequent 
instance  of  TRICK-HAS-POINTS  was  recognized,  as  in  DKRIV6: 

(AVOID-TAKING- POINTS  (TRICK)) 

6:1-20  -  [by  analysis]  - > 

(ACHIEVE  (NOT  (AND  [=  ( TR ICK-WINNER )  ME] 

[EXISTS  C3  (CARDS-PLAYED)  (HAS-POtNTS  C3 ) ] ) ) ) 

6:21  ---  [RECOGNIZE  by  RULE  123 ]  -  — > 

(ACHIEVE  (NOT  (AND  [*  ( TR ICK-WINNER )  ME] 

[HAVE-POINTS  (CARDS-PLAYED)]))) 

6:22  ---  [RECOGNIZE  by  RULE  123]  ---> 

(ACHIEVE  (NOT  (AND  [«  ( TR ICK-WI NNE R )  ME]  [TRICK-HAS-POINTS]))) 

Reformulating  AVOID- TAKING- POINTS  in  terms  of  a  conjunction  and  recognizing  the  second 
conjunct  as  TRICK-HAS-POINTS  would  make  it  possible  to  apply  any  previously  derived  methods  for 
evaluating  TRICK-HAS-POINTS.  In  particular,  when  the  methods  predicted  that  a  trick  would  not 
have  points,  any  card  could  be  played  without  fear  of  taking  points. 

As  implemented,  FOO  is  used  to  operationalize  expressions  independently  of  each  other.  However, 
retrieving  solutions  of  previously  solved  subproblcms  would  be  necessary  in  a  practical 
operationalizer  to  avoid  the  expense  of  solving  every  problem  from  scratch.  This  simple  technique 
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proved  useful  in  die  Logic  Theorist  program,  which  retrieved  previously  generated  proofs  to  prove 
parts  of  new  theorems  [Newell  57|.  The  role  of  recognition  in  such  a  process  is  to  relate  new 
problems  to  previously  solved  ones,  thereby  broadening  the  range  of  application  of  stored  solutions. 

6.3.2.  Recognition  by  Matching  versus  Recognition  by  Analysis 

Some  of  FOO's  concept  definitions  can  be  criticized  for  the  serendipity  with  which  they  match 
synthesized  expressions  recognized  in  terms  of  those  concepts.  RULF123,  die  rule  for  recognizing  an 
expression  as  a  know  n  concept,  is  quite  primitive:  it  just  tests  for  a  literal  match  between  expression 
and  concept  definition,  allowing  for  variable  substitutions.  To  illustrate,  consider  die  recognition 
transformation 

(FOR-SOME  Cl  ( CARDS- IN-HAND  ME) 

(AMD  [PLAY  ME  Cl]  [IN-SUIT  Cl  SO])) 

---  [RECOGNIZE]  ---> 

(PLAY-SUIT  ME  SO) 


RULH123  can  be  used  to  make  diis  transformation  if  PLAY-SUIT  is  defined  as 

PLAY-SUIT  * 

(LAMBDA  (PS) 

(FOR-SOME  X  (CAROS- IN-HAMO  ME) 

(AMO  [PLAY  P  X]  [IN-SUIT  X  S]))) 


This  would  be  done  by  identifying  P,  S,  and  x  with  ME,  SO,  and  Cl.  respectively.  However. 

RULF.123  would  not  be  able  to  make  die  same  transformation  given  the  almost  identical  definition 

PLAY-SUIT  = 

(LAMBDA  (P  S) 

(FOR-SOME  X  (CAROS) 

(AND  [PLAY  P  X]  [PI-SUIT  X  S]))) 

The  problem  here  is  chat  (CAROS- im-uaho  me)  doesn't  match  (CARDS).  In  short.  RUI.E123  is 
not  robust  with  respect  to  variations  in  the  definition  of  the  concept  to  be  recognized. 

Such  variations  could  be  allowed  by  using  analysis  for  recognition.  An  expression  (f  e1 ...  e  )  could 
be  matched  to  a  definition  (lambda  (x(  ...  x  )<body»  by  solving  for  \l  ...  x  in  die  equation 

(feL ...  en)  =  <body> 


In  the  above  example,  this  would  mean  solving  for  P  and  S  in 
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(=  [F0R-S0ME  Cl  (CAROS- IN-HANO  ME) 

(AND  [PLAY  ME  Cl]  [IN-SUIT  Cl  SO])] 
[FOR-SOME  X  (CAROS) 

(AND  [PLAY  P  X]  [IN-SUIT  X  S])]) 


This  might  involve  showing  that  a  card  must  be  in  player  P’s  hand  in  order  for  P  to  play  it,  i.e.. 

(=>  [PLAY  P  X]  [IN  X  ( CARDS-  IN-HANO  P)]) 

Using  analysis  in  recognition  would  increase  the  range  of  expressions  recognizable  as  a  given 
concept,  at  die  cost  of  slowing  down  the  recognition  process  in  the  easy  cases  handled  by  die  simple 
matching  algorithm.  As  implemented,  RULE123  recognizes  an  expression  (f ...)  by  first  retrieving 
each  concept  whose  definition  has  the  form  (lambda  (...)  (f ...));  all  such  concepts  are  indexed  under  f. 
The  expression  is  then  matched  against  each  retrieved  definition  to  find  the  concept  that  fits.  The 
total  process  is  reasonably  fast.  Recognition-by-analvsis  would  be  much  slower,  especially  if  it  tested 
concepts  other  than  those  with  definitions  of  the  form  (lambda  (...)  (f ...)).  (This  might  be  necessary 
to  tolerate  differences  between  the  stored  definition  and  the  expression  to  be  recognized.)  To 
simulate  the  robustness  of  recognition-by-analysis  without  sacrificing  the  speed  of  recognition-by- 
matching,  I  tailored  the  definitions  of  a  few  concepts  to  fit  synthesized  expressions  that  occurred  in 
the  derivations.  In  most  cases  this  simply  shortened  an  already  operational  expression. 


6.4.  Exploiting  Properties  of  the  Task  Domain 

Knowledge  about  task  domain  structure  is  reflected  in  implicit  and  explicit  assumptions  made  in 
the  various  derivations.  Examination  of  these  assumptions  sheds  light  on  a  central  question: 

What  kind  of  knowledge  about  the  task  domain  is  used  in  operationalising  advice? 

(§6.4.1)  examines  the  central  assumption  that  expressions  used  in  advice  and  concept  definitions 
are  well-defined.  (§6.4.2)  describes  some  constructs  containing  embedded  assumptions.  (§6.4.3) 
considers  definitions  as  assertions  about  the  task  domain.  (§6.4.4)  discusses  explicit  assumptions 
about  the  task  domain  made  in  some  of  the  derivations. 


6.4.1.  The  Well-definedness  Assumption 

If  the  knowledge  base  is  a  consistent  model  of  the  task  domain,  and  advice  about  the  task  is 
meaningful,  certain  properties  of  the  domain  arc  captured  by  a  general  well-defmedness  assumption: 

Assume  any  expression  in  a  definition  or  heuristic  will  be  well-dejined  whenever  it  is  used. 
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In  particular,  expressions  of  the  form  (the  x  S  P  )  are  only  well-defined  when  S  contains  an 

clement  satisfying  P  and  that  element  is  unique  in  S.  For  instance,  consider  die  definitions 

HIGHEST  * 

(LAMBDA  (S) 

(THE  C  S 

(FORALL  X  S  (NOT  (HIGHER  X  C ) ) ) ) ) 

(WINNING-CARD) 

=  (HIGHEST-IN-SUIT-LED  (CAROS-PLAYED) ) 

=  (HIGHEST  (CARDS- IN-SUIT -LED  ( CARDS- PLAYED) ) ) 

The  function  highest  is  only  well-defined  when  S  has  a  unique  highest  element:  thus  the  concept 
(WINNING-CARD)  only  makes  srnse  if  (CARDS- IN-SUIT-LED  ( CARDS- PLAYED ) )  contains  a  card 
higher  in  the  card  ordering  dian  all  die  others. 

The  fact  that  (WINNING-CARD)  is  well-defined  reflects,  among  other  diings.  that  Hearts  is  played 
with  a  single  deck  of  cards  --  if  two  of  the  same  card  were  played,  which  would  win  the  trick? 
Actually,  there  arc  situations  in  which  (WINNING-CARO)  is  undefined,  for  example  during  the 
dealing,  passing,  and  scoring  phases  of  the  game,  when  (CARDS-played)  is  undefined  or  empty. 
However.  the  (winning -CARD)  concept  is  not  used  during  these  phases.  The  wcli-definedncss 
assumption  requires  only  that  a  concept  be  well-defined  whenever  it  is  used.  More  precisely,  if  a  task 
definition  is  viewed  as  an  executable  program,  dicn  an  expression  is  used  at  those  points  in  die 
execution  of  the  program  when  it's  evaluated. 

Note  also  diat  the  assumption  talks  only  about  wcil-dcfmedness\  it  says  nothing  about  ewtluaidiiy. 
For  example,  consider  die  predicate 

OUT  =  (LAMBDA  (C)  (EXISTS  P  (OPPONENTS  ME)  (HAS  PC))) 

This  predicate  is  well-defined,  but  cannot  be  computed  in  die  straightforward  way  by  player  ME 
without  violating  the  rules  of  the  game  (no  peeking  at  opponents’  hands).  Even  using  the  pigeon¬ 
hole  principle  (§2.2),  there  is  no  perfect  way  to  decide  if  a  card  is  out,  since  it  may  have  been  the  hole 
card. 

6.4.2.  Embedded  Assertions 

An  assertion  C  is  said  to  be  embedded  in  an  expression  e  if  C  must  be  true  in  order  for  e  to  make 
sense.  For  example,  any  expression  of  the  form  (the  x  S  P  )  contains  die  embedded  assertion 
(cxists-unique  x  S  P  ).  Similarly,  the  construct  (partition  Sj  ...  Sn)  contains  die  embedded  assertion 
(disjoint  Sj ...  Sn).  This  assertion  is  made  into  an  explicit  assumption  by 
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RUI.E15:  (partition  Sj ...  Sfl)  ->  (union  S;  ...  Sn);  assume  (disjoint  ...  Sn) 


In  its  explicit  form,  this  assumption  can  be  used  by 

RULF19:  (diff  [join  ...  S  ...  SJ  S)  ->  (join  Sj ...  Sn)  if  (disjoint  ...  Sn) 


This  is  illustrated  in  DF.R1V4: 

(0IFF  [PARTITION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)] 

[PROJECT  HANO  (OPPONENTS  ME)]) 

4:10  ---  [ELABORATE  by  RULE  15]  ---> 

(DIET  [UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)] 

[PROJECT  HAND  (OPPONENTS  ME)]) 
assume  (DISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

4.11-15  —  [by  analysis]  — > 

(UNION  (DIFF  [UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)] 

[HANDS  (PLAYERS)]) 

(INTERSECT  [UNION  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)] 

[SET  (HAND  ME)])) 

4:16-18  —  [by  RULE  19 ,  previous  assumption]  — > 
(UNION  [UNION  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)] 

(INTERSECT  [UNION  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)] 

[SET  (HAND  ME)])) 


In  this  example,  the  disjointness  assertion  follows  from  the  assumption  that  (partition  ...)  is  well- 
defined,  and  models  the  fact  that  hands,  piles,  deck,  pot,  and  hole  arc  distinct  locations.  This 
property  is  exploited  by  die  special-case  reduction  rule  RULE19,  whose  condition  tests  for 
disjointness.  Thus  the  implicit  disjointness  assumption  and  the  way  it  is  used  to  satisfy  a  special-case 
test  arc  both  quite  clear.  For  the  construct  (the  x  S  P  ),  die  implicit  unique-existence  assumption  is 
clear,  but  how  it’s  used  is  not. 
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6-4.3.  Definitions  ns  Assertions  about  a  Modelled  Domain 

One  answer  to  the  question  of  how  such  assumptions  are  used  view's  die  know  ledge  base  as  a  model 
of  external  phenomena.  Assumptions  of  well-definedness  reflect  predictions  about  these  phenomena, 
e.g.,  "at  the  end  of  every  trick,  the  pot  w  ill  contain  exactly  one  highest  card  in  the  suit  led."  Properties 
of  the  task  domain  are  exploited  to  simplify  the  task  description.  This  affects  operationalization 
insofar  as  simpler  task  descriptions  arc  easier  to  reason  about.  The  definition  of  a  trick  wouldn't  be  as 
simple  if  it  foiled  to  exploit  the  uniqueness  of  the  trick-winner.  For  example,  the  event  of  die  w  inner 
taking  the  trick  could  not  be  defined  as 

(TAKE-TRICK  [THE  P  (PLAYERS) 

(FORALL  C  (CAROS- PLAYED ) 

(NOT  (HIGHER  C  (CARD-OF  P ) )  ) ) ] ) 

An  extra  quantifier  would  be  needed  to  deal  with  a  possibly  non-unique  "player  of  the  highest 
card”: 

(FOR-SOME  P  [SET-OF  Q  (PLAYERS) 

(FORALL  C  (CARDS-PLAYED) 

(NOT  (HIGHER  C  (CARD-OF  Q) ) ) ) ] 

(TAKE-TRICK  P ) ) 

Both  expressions  describe  the  same  event,  but  the  second  is  presumably  harder  to  reason  about. 

If  the  knowledge  base  is  a  model  of  external  pheonomena,  then  by  the  well-defincdncss 
assumption,  every  function  in  the  knowledge  base  represents  an  assertion  about  the  domain:  namely 
that  the  external  entity  denoted  by  the  function  is  uniquely  determined  by  the  values  of  its  arguments 
plus  the  values  of  any  fluents  in  its  definition.  (The  latter  rather  gaping  loophole  could  be  closed  by 
replacing  those  fluents  with  explicit  arguments.)  For  example,  consider  the  definition 

(WINNING-CARD)  =  (HIGHEST  (CARDS- IN-SUIT-LED  (CARDS-PLAYED))) 

This  definition  implicitly  asserts  that  the  winning  card  (the  external  entity  modelled  by 
winning-CARD)  is  uniquely  determined  by  the  cards  played  in  the  trick,  independent  of  say,  what 
cards  have  been  taken  so  for.  This  property  of  tire  game  makes  it  simpler  to  describe  (and  reason 
about)  than  if  the  winning  card  depended  on  the  locations  of  ail  52  cards,  the  current  score,  and  the 
day  of  the  week.  The  discovery  of  such  invariances  is  a  central  problem  in  experimental 
science  [Langley  79 j. 
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6.4.4.  Explicit  Assumptions  about  the  Task  Domain 

Some  of  the  deri  atiors  involve  explicit  assumptions  about  the  task  domain  -generated  in  the 
course  of  applying  various  transformations.  Such  assumptions  are  illustrated  in  DERIV3,  where  the 
goal  is  to  construct  a  plan  for  lushing  the  Queen  of  spades.  A  subgoal  is  to  make  it  legal  for  the 
player  (QSO)  who  has  the  Queen  to  play  it.  This  happens  if  player  (QSO)  has  the  lead,  or  if  spades 
are  led.  However,  the  first  case  violates  the  subgoal  of  constraining  player  (QSO)’s  options.  FOO 
doesn’t  know  about  the  flexibility  associated  with  hav;ng  the  lead;  1  simulated  this  knowledge  by 
assumption: 

RULE342;  ( =  c  e)  ->  T  by  assumption,  where  c  is  a  constant 
(=  S  (SUIT-LED)) 

3:26  ---  [ASSUME  by  RULE342]  ---> 

T 

assume  (SUIT-LED)  =  S 

RULF.349:  (  =  >  C  P)  •>  T  by  assuming  P  false 
(=>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)]  [NEQ  (SUIT-OF  C3)  H])) 

3:80  ---  [ASSUME  by  RULE349]  ---> 

T 

assume  (LEADING  (QSO))  =  NIL 

These  assumptions  helped  reduce  the  goal  of  flushing  the  Queen  to  the  goal  of  making  player 
(QSO)  keep  playing  spades.  The  fact  that  these  conditions  are  sufficient  to  force  player  (QSO)  to  play 
a  spade  follows  from  the  rules  of  the  game.  This  deduction  was  simulated  as  follows: 

RULE351:  (achieve  P)  ->  (achieve  P^ ...  Pn)  if  assumptions  ...  Pn  reduce  original  goal  to  P 

(ACHIEVE  (PLAY-SPAOE  (QSO))) 

3:88  ---  [REDUCE  by  RULE351]  — > 

(ACHIEVE  (AND  [»  (LEADING  (QSO))  NIL]  [=  (SUIT-LED)  S])) 

This  reduction  led  to  an  operational  plan  for  flushing  the  Queen  by  repeatedly  leading  spades. 

Another  explicit  assumption  reflecting  a  property  of  the  task  domain  is  used  in  DF.RIV10: 

RULE373:  (at  c  hole)  ->  nil  by  assumption 
(AT  XI  HOLE) 

10:19  ---  [ASSUME  by  RULE373]  ---> 

NIL 


The  knowledge  incorporated  in  this  assumption  is  that  fact  that  the  probability  of  any  given  card 
being  die  hole  card  is  often  low  enough  to  ignore  (§1.3.3). 
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6.5.  Knowledge  Base  Search 

A  key  feature  of  1 00  is  the  ability  to  search  through  the  knowledge  base  of  concept  definitions  for 
a  concept  satisfying  a  specified  condition  or  for  a  specified  relationship  between  given  concepts. 
Some  types  of  search  arc  based  on  the  assumption  dial  the  know  ledge  base  is  complete  in  a  certain 
way  (§6.5.1).  Another  type  of  search  exploits  the  fact  that  concepts  included  in  die  knowledge  base 
are  more  likely  to  be  useful  than  randomly  generated  expressions  (§6.5.2).  Knowledge  base  search 
can  find  an  action  with  a  specified  effect  (§6.5.3),  or  a  testable  necessary  condition  for  an  assertion 
diat  cannot  be  directly  evaluated  (§6.5.4).  The  ability  to  search  through  die  knowledge  base  implies 
that  simply  adding  die  right  concept  to  the  knowledge  base  may  enhance  the  ability  to 
operationalize  (§6.5.5). 


6.5.1.  Closure-based  Search 


Some  t>  pes  of  search  exploit  closed-universe  assumptions.  For  example,  the  follow  ing  rules  assume 
that  if  an  event  F.  can  occur  during  a  scenario  S.  the  definition  of  S  mentions  F  directly  or 
indirectly  (§2.4.5.2): 

RULE57:  (during  S  F)  ->  nil  if  sub-events  of  $  and  abstractions  of  F  do  not  intersect 

RULF.306:  (F  ...  e  ...)  ->  (HSM  with  [problem  :  (F  ...  e  ...)]  [choicc-scq  :  (choicc-seq-of  c)])  if  a 
sequence  subevent  of  c  contains  a  choice  event  of  the  form  (choose  x  S  F.  ) 

RLT.F.308:  (choicc-scq-of  S)  ->  ml  if  no  sub-event  of  S  is  a  choice  event 


This  assumption  permits  certain  questions  to  be  answered  quickly  by  intersection  search  through 
the  knowledge  base  (§5.6): 

( OUR  I  MG  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)]  [TAKE  ME  QS]) 

5:8  ---  [COMPUTE  by  RULE57]  ---> 

MIL 

(DURING  [EACH  PI  (PLAYERS)  (PLAY-CARD  PI)]  [TAKE - PO I  NTS  ME]) 

6:5  ---  [COMPUTE  by  RULE57]  ---> 

NIL 

(DURING  [ROUND- IN- PROGESS] 

[EXISTS  PI  (OPPONENTS  ME)  (GET-CARD  PI  XI  LOCI)]) 

10:10  ---  [COMPUTE  by  RULE57]  ---> 

NIL 

(DURING  [ROUND- IN-PROGRESS] 

[EXISTS  Cl  (CAROS) 

(AND  [GET-CARD  PO  Cl  LOCI]  [IN-SUIT  Cl  SO])]) 

12:11  ---  [COMPUTE  by  RULE57]  ---> 

NIL 


r 
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(CHOICE-SEQ-OF  (TAKE-TRICK  (TRICK-WINNER) ) ) 

2:7  ---  [COMPUTE  by  RULE308]  ---> 

NIL  since  no  sub-event  of  TAKE-TRICK  is  a  choice  event 

(DURING  (TRICK)  (TAKE-POINTS  ME)) 

2:3  ---  [by  RULE306]  ---> 

( HSM1  WITH  [PROBLEM  :  (DURING  (TRICK)  (TAKE-POINTS  ME))] 

[CHOICE -SEQ  :  (CHOICE-SEQ-OF  (TRICK))]) 
since  choice  event  PLAY-CARD  is  in  a  sequence  sub-event  of  (TRICK) 

(LEGAL-CANTUS!  (CANTUS)) 

13:1  ---  [by  RULE306]  ---> 

(HSM1  WITH  [PROBLEM  :  (LEGAL-CANTUS!  (CANTUS))] 

[CHOICE -SEQ  :  (CHOICE-SEQ-OF  (CANTUS))]) 
since  choice  event  CHOOSE-NOTE  is  in  sequence  event  (CANTUS) 


6.5.2.  Plausible  Generation  of  Sufficient  Conditions 


Other  types  of  knowledge  base  search  exploit  the  fact  that  defined  concepts  are  likely  to  be  useful. 
For  example,  a  predicate  that  someone  has  bothered  to  define  is  likely  to  be  satisfied  reasonably  often 
by  some  combination  of  task  situation  components.  (Most  words  arc  not  invented  to  describe  things 
that  seldom  arise.)  This  property  motivates  the  use  of  knowledge  base  search  for  plausible  generation 
of  concepts  satisfying  desired  properties.  For  instance,  the  following  two  rules  try  to  generate 
sufficient  conditions  for  predicates  that  can't  be  evaluated  directly: 

RULF.227:  (P  ...)  ->  (  =  >  [R  ...]  [P  ...])  if  (R  ...)  is  true  and  definition  of  R  mentions  P 

(VOID  P0  SO) 

11:1-6  ---  [by  RULE227,  analysis]  ---> 

(=>  [LEGAL  PI  (CARD-OF  PI)]  [VOID  P0  SO]) 
since  (LEGAL  PI  (CARO-OF  PI))  is  true  for  all  PI 
11:7-18  —  [REOUCE  by  analysis]  - > 

(AND  [BREAKING-SUIT  PO]  [*  (SUIT-LED)  SO]  [FOLLOWING  P0]) 

RULE319:  (P  ...)  ->  add  annotation  (R  ...)  is  necessary  when  C, 

where  definition  of  R  mentions  P.  and  C  is  result  of  reducing  ( =  >  [P  ...]  [R  ...]) 

(HAS  PI  C2 ) 

2:28  ---  [by  RULE319]  — > 

(HAS  PI  C2)  ;  [=>  (OUT  C7)  IF  (=>  [HAS  PI  C2]  [OUT  C7])] 

Z:29-39  -  [REDUCE  by  analysis]  — > 

(HAS  PI  C2)  ;  [=>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME))] 

(HAS  PI  C2) 

2:40  ---  [by  RULE319]  ---> 

(HAS  PI  C2)  ;  [=■>  (NON-VOID  P5)  IF  (O  [HAS  PI  C2]  [NON-VOID  P5])] 
2:41-57  —  [REDUCE  by  analysis]  - > 

(HAS  PI  C2)  ;  [=>  (NON-VOID  PI)  IF  (IN-SUIT  C2  (SUIT-LED))] 


Both  RULE227  and  RULE319  search  the  knowledge  base  for  a  predicate  R  whose  definition 
mentions  P  directly  or  indirectly.  This  requirement  that  R  be  relevant  to  P  improves  the  chances  that 
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f 

[  ( =  >  |R  ...]  [P  ...])  or  {  =  >  [P  ...]  [R  ...))  is  reducible  (by  partial  matching)  to  an  evaluable  expression 

(§2.6.4.!). 


6.5.3.  Finding  Actions  with  Specified  Effects 


A  similar  use  of  the  knowledge  base  is  to  find  an  action  with  a  specified  effect.  Often  this  is 
achieved  by  recognizing  an  action  concept  whose  definition  matches  a  ''escribed  change  (§2.4).  This 
doesn’t  always  work,  for  example  when  the  specified  effect  is  dial  die  action  leave  some  condition 
unchanged.  When  recognition  doesn’t  work,  a  less  efficient  but  more  robust  alternative  is  a  generate- 
and-test  approach:  generate  candidate  actions  from  die  knowledge  base  of  defined  action  concepts 
and  test  each  one  by  analysis.  In  practice,  this  search  was  partly  simulated  by  hand-selecting  the 
correct  concept  from  the  set  of  defined  action*  but  this  concept  was  tested  using  t  oo’s  analysis  rules. 
In  die  mles  below,  A  is  an  action  selected  from  the  knowledge  base: 

RUI  .F.234:  (P  ...)  ->  (was-during  (current  A]  (P  ...j)  if  (not  tduring  [A  ...]  [undo  P])) 

(VOID  PO  SO) 

12:1-13  ---  [by  RULE234,  analysis]  ---> 

(WAS-DURING  [CURRENT  ROUND- I N - PROGRESS]  [VOID  PO  SO]) 
since  (NOT  (DURING  [ROUND- IN-PROGRESS]  [UNDO  (VOID  PO  SO)])) 


RU1  H254:  (change  P)  ->  (A  ...)  if  ( =  >  (A  ...j  (change  PJ),  where  A  is  an  action 
(UNDO  (HAS  ( QSG )  C3 ) ) 

3:46-61  ---  [by  RULE254 ,  analysis]  ---> 

(PLAY  (QSO)  C3 ) 

since  («>  [PLAY  PI  C4]  [UNDO  (HAS  (QSO)  C3)]) 
if  C4  =  C3  and  PI  =  (QSO) 


RUi.F.356:  (P  ...)  ->  (or  [was-durmg  [current  \]  (cause  (P  ...)]]  [before  [current  A]  [P  ...]]) 

(AT  QS  (PILE  P3 ) ) 

4:47  ---  [by  RULE356]  ---> 

(OR  [WAS-DURING  [CURRENT  ROUND- IN-PPCGRESS] 

[CAUSE  (AT  QS  (PILE  P3))]] 

[BEFORE  [CURRENT  ROUND  - 1 N- PROGRESS ]  [AT  QS  (PILE  P3)]]) 

RL'1  F370:  ( it  (set-of  x  S  P^))  -> 

(-  \  #  (set-of  x  S  (before  [current  A|  P^))j 
[it  (set-of  x  S  (was-during  [current  Aj  [undo  P  j))}) 

(#  (SET-CF  XI  ( CAROS -IN-SUIT  SO)  (OUT  XI))) 

10:4-12  ---  [by  PULE370,  analysis]  ---> 

(-  [#  (SET-OF  XI  (CAROS-IN-SUIT  30) 

(BEFORE  [CURRENT  ROUND- IN-PROGRESS]  [OUT  XI]))] 

[#  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(WAS-DURING  [CURRENT  ROUND- IN-PROGRESS]  [UNDO  (OUT  XI)]))]) 


k. 
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6.5.4.  Find  a  Necessary  Condition 

A  similar  use  of  the  knowledge  base  is  to  find  a  necessary  condition  for  a  given  expression.  A  rule 
that  tests  a  necessary  condition  for  membership  in  a  collection  is 

RULE304:  (in  e  S)  ->  nil  if (R  c  [fS]),  where  R  is  an  ordering  and  SUPERLATIVE  of  R  is  f 

(IN  (NEXT  NOTE)  CANTUS-1) 

14:73-75  ---  [by  RULE304]  ---> 

NIL  since  (HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-1)) 

The  domain-specific  ordering  R,  in  this  case  the  musical  relation  HIGHER,  is  selected  from  the 
ordering  concepts  in  the  knowledge  base. 

A  rule  for  refining  the  disjoint  subsets  method  (§2.3. 1.5)  searches  the  knowledge  base  for  a 
necessary  condition  P  for  membership  in  the  set  H: 

RUL.E200:  (Prdisjoint  H  S  U)  ->  (Pr-disjoint  H  (filter  S  P)  (filter  U  P))  if  (filter  H  P)  =  H, 
where  P  is  a  unary  predicate  selected  from  the  knowledge  base  of  domain  concepts 

RULE200  refines  an  estimate  of  the  probability  that  player  PO  is  void  in  suit  SO  by  finding  the 

concept  of  a  card  being  OUT  (held  by  an  opponent): 

(PR-OISJOINT  (CAROS- IN-HANO  PO)  (CARDS- IN-SUIT  SO)  (CARDS)) 

9:27-40  ---  [REFINE  by  RULE200 ,  analysis]  ---> 

(PR-OISJOINT  (CARDS-IN-HAND  PO)  ( CARDS-OUT- IN-SUIT  SO)  (CARDS-OUT)) 

Since  (FILTER  (CARDS-IN-HAND  PO)  OUT)  =  (CARDS-IN-HAND  PO) 
assuming  (IN  PO  (OPPONENTS  ME)) 

6.5.5.  Having  a  Concept 

An  interesting  consequence  of  using  methods  that  search  through  a  knowledge  base  of  domain 
concepts  is  that  the  mere  presence  of  the  right  concept  in  the  knowledge  base  may  greatly  improve  the 
ability  to  operationalize  advice  by  enabling  the  derivation  of  solutions  not  otherwise  possible.  This 
phenomenon  appears  to  capture  the  flavor  of  a  familiar  aspect  of  human  thought  -  the  usefulness  of 
“having"  a  concept  relevant  to  the  problem  at  hand.  For  example,  my  ability  to  reason  about  Hearts 
improved  when  I  was  told  about  the  concept  of  distribution.  This  gave  me  a  powerful  reasoning  tool; 
by  reformulating  a  question  about  a  game  situation  in  terms  of  distribution,  I  was  able  to  compute  the 
answer  easily: 

1.  I’m  pretty  sure  Mike’s  got  the  Jack  of  diamonds:  docs  he  have  any  other  diamonds  left? 

2. 1  know  there  arc  three  diamonds  out;  they're  probably  distributed  1-2  or  2-1. 
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3.  There's  roughly  a  50-50  chance  the  Jack's  his  last  diamond,  so  it’s  worth  leading  my  Ace. 

This  probability  estimate  is  actually  wrong,  but  it  reflects  my  actual  reasoning  in  a  recent  game. 
(Despite  my  sloppy  reasoning,  my  conclusion  was  correct:  1  played  the  Ace  and  flushed  the  Jack.) 

Although  FOO  cannot  at  present  exploit  a  concept  as  sophisticated  as  "distribution"  just  by 
knowing  its  definition  (it  would  be  interesting  to  try  to  get  it  to  do  so  on  tire  same  example),  it  was 
able  to  refine  an  estimate  of  the  probability  of  a  void  because  the  concept  OUT  happened  to  be 
defined  in  the  knowledge  base,  having  been  used  in  die  advice  "if  die  Queen  is  out,  try  to  flush  it.” 


6.6.  Missing  Rule  Conditions  as  Domain  Knowledge 

The  act  of  applying  a  aile  assumes  that  doing  so  is  semantically  appropriate  for  the  problem  at 
hand,  e.g.,  logically  valid  or  sound.  It  is  not  always  easy  to  test  mechanically  whether  a  rule  is 
semantically  appropriate,  or  even  to  formulate  precisely  what  tire  test  should  be.  Many  of  roo's  rules 
are  syntactically  applicable  to  expressions  to  which  it  would  be  inappropriate  to  apply  them. 
Restricting  the  rules  to  prevent  such  inappropriate  applications  would  involve  adding  extra  rule 
conditions.  Such  conditions  constitute  domain  knowledge  1  exploited  (consciously  or  otherwise) 
when,  in  my  role  of  problem-solver,  1  chose  to  apply  die  rules.  Although  this  knowledge  is  missing  in 
FCO,  it  was  certainly  used  in  operationalization,  and  is  of  interest  for  diat  reason;  an 
operationalization  problem-solver  would  presumably  need  such  knowledge.  Also,  the  missing  rule 
conditions  are  interesting  as  a  potential  locus  for  knowledge  acquisition.  That  is.  they  suggest  useful 
kinds  of  things  to  learn  about  a  domain,  whether  from  experience  or  by  asking  an  expert  (§8.1.7). 

This  section  tries  to  characterize  domain  properties  corresponding  to  such  missing  rule  conditions, 
although  some  of  them  are  not  readily  expressible  in  domain-related  terms.  (§n.6.1)  discusses 
knowledge  about  die  capabilities  of  die  runtime  mechanism:  die  conditions  it  can  affect  (§6.6. 1.1), 
die  information  it  can  know  (§6.6. 1.2).  and  the  processes  occurring  in  die  task  en\  ironment  (§6.6. 1.3). 
(§6.6.2)  discusses  knowledge  about  domain  concepts  with  certain  mathematical  properties,  such  as 
monotonic  and  injective  functions.  (§6.6.3)  discusses  rules  that  exploit  die  assumption  that  distinct 
constants  denote  distinct  entities.  (§6.6.3)  discusses  the  validity  of  rules  for  manipulating  logical 
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6.6.1.  Knowledge  about  Runtime  Limitations 

Some  rule  conditions  missing  in  FOO  involve  knowledge  about  what  is  and  isn't  possible  in  the  task 
environment:  what  actions  can  be  performed,  what  quantities  can  be  evaluated. 

6.6. 1.1  Immutable  Conditions 

A  condition  that  can’t  be  changed  by  any  action  in  the  task  domain  is  called  immutable ,  e.g.: 

(IN  C3  (DIFF  (CARDS)  (SET  QS))) 

(IN-SUIT  Cl  SO) 

(IN  Cl  (CARDS)) 

These  conditions  arc  immutable  in  that  no  legal  action  in  Hearts  can  affect  them:  the  set  of  cards  is 
constant,  the  suit  of  a  card  can't  be  changed,  and  a  card  can’t  be  changed  into  the  Queen  of  spades 
nor  can  the  Queen  be  turned  into  another  card  (however  much  some  players  might  wish). 

The  following  rule  is  logically  valid  (preserves  equivalence)  when  Pj ...  Pn  are  immutable: 

RULE35:  (affect  (and  Pt ...  P  ...  Pn))  ->  (and  [affect  P]  ...  Pn) 

Knowledge  about  what  conditions  are  inherently  immutable  in  a  given  task  domain  seems  useful  in 
general.  One  way  to  deduce  it  automatically  would  assume  that  the  knowledge  base  contains  all 
actions  possible  (or  legal)  in  the  task  environment.  A  condition  neither  caused  nor  undone  by  any 
known  action  would  be  considered  immutable. 

6.6.1. 2  Kvaluability 

A  similar  kind  of  knowledge  involves  the  ability  to  predict  what  will  be  evaluable  at  runtime.  This 
point  is  illusuatcd  in  DERIV9  by  the  use  of  the  disjoint  subsets  method  (§2.3): 

RULE189:  (P ...  S  ...)  •>  (h  (disjoint  S  S'))  for  suitable  h  and  S’, 

(where  S  will  be  unknown  at  runtime} 

As  implemented.  FOO  docs  not  test  the  bracketed  condition.  The  problem  in  DF.RIV9  is  to  find  a 
way  of  deciding  whether  an  opponent  PO  is  void  in  suit  SO: 

(EVAL  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))) 


f 


RULE189  is  relevant  to  this  problem  because  player  me  knows  the  size  of  an  opponent’s  hand  but 
not  its  contents.  If  the  opponent's  hand  were  visible,  it  would  not  be  necessary  to  use  the  disjoint 
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subsets  method;  if  the  si/e  of  die  hand  were  unknown,  it  would  not  be  possible  to  use  diemethod. 
Thus  the  decision  to  use  die  method  is  based  on  knowledge  about  what  information  will  be  available 
to  the  task  agent  at  runtime  (§8.1.1). 

Similar  considerations  figure  later  in  DFR1V9.  For  example,  the  disjoint  subsets  method  requires 
finding  a  set  of  known  size  to  play  die  role  of  S’  in  RULF189.  An  obvious  candidate  is  the  set 
(SET-OF  Cl  (CAROS- in-hand  PO)  (IN-SUIT  Cl  SO) ).  However,  diis  set  is  unsuitable  because 
player  HE  cannot  generally  determine  its  size;  indeed,  the  problem  of  doing  so  subsumes  the  problem 
of  telling  whether  player  PO  is  void.  Hie  set  (CARDS-IN-SUIT  SO)  always  has  13  elements  and  is 
therefore  a  suitable  S'.  The  method  also  requires  a  common  superset  L'  of  S  and  S’  whose  size  is 
known.  The  most  obvious  common  superset  of  S  and  S'  is  their  union,  but  its  size  is  unknown  for  this 
problem;  instead.  (CARDS)  is  used,  since  its  size  is  known  to  be  52.  Thus  die  choice  of  S’  and  U  is 
based  on  knowledge  about  which  set  si/es  can  be  determined  at  aintime. 

l  ater  the  solution  is  refined  by  finding  a  predicate  P  satisfied  by  all  of  S.  and  using  it  to  filter  S’ 
and  lr.  To  evaluate  the  refined  expression,  player  ME  must  be  able  to  compute  the  sizes  of  (filter  S’  P) 
and  (filter  U  P).  Die  predicate  OUT  is  used  for  P.  since  player  ME  can  compute  the  total  number  of 
cards  out  and  (ignoring  die  hole  card)  the  number  of  cards  out  in  suit  So.  Subsequently,  functional 
dependence  analysis  (§2.8.2)  is  used  to  produce  a  Oth  order  approximate  solution,  and  die  quantity 
( #C  ARDS -OUT  -  IN- SUIT  SO)  is  chosen  as  die  independent  variable  because  it's  evaluable  and  its 
possible  values  arc  ordered  (otherwise  functional  dependence  wouldn't  apply).  In  short,  applying  die 
disjoint  subsets  method  and  functional  dependence  analysis  to  diis  problem  requires  knowledge  about 
w  hat  can  be  evaluated  at  runtime  using  the  data  available  tv  the  task  agent. 

Knowledge  about  what  can  and  can't  be  evaluated  at  runtime  could  be  discovered  by  trial  and 
error.  An  analytic  approach  would  decide  the  evuluability  of  a  given  expression  by  trying  to 
transform  it  into  an  operational  expression.  An  empirical  approach  would  record  how  often  the 
expression  was  successfully  evaluated  at  amtime  (§8.1.7). 

6.6. 1.3  Processes 

Another  kind  of  knowledge  about  actions  in  the  task  domain  involves  processes  Co  which  advice 
refers.  For  example,  these  rules  assume  that  the  set  or  sequence  S  is  being  extended: 

RUI.F277:  (change  (fS))  ->  (R  [f  (change  S)j  [f  SJ).  where  f  is  extremum  for  die  ordering  R 

RUI.F300:  (next  ( f  S))  ->  (f  (change  S))  if  (R  [f  (change  S)|  [f  S]).  where  f  is  extremum  for  R 
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Here  (change  S)  denotes  (diff  (next  S)  S)  but  (change  (f  S))  denotes  (*  [f  SI  [next  (f  S)|).  The  fact 

that  CANTUS- 1  is  being  extended  is  used  in  DER1V14  to  show  that  adding  new  notes  to  CANTUS- 1 

changes  the  climax  if  the  highest  new  note  is  higher  than  the  highest  old  note: 

(CHANGE  (HIGHEST  CANTUS-1)) 

14:42  ---  [REDUCE  by  RULE277]  ---> 

(HIGHER  [HIGHEST  (CHANGE  CANTUS-1)]  [HIGHEST  CANTUS-1]) 


The  same  fact  is  used  to  deduce  that  the  next  climax  is  the  highest  new  note  if  it’s  higher  than  the 
old  climax: 

(NEXT  (HIGHEST  CANTUS-1)) 

14:55-57  ---  [REDUCE  by  RULE3Q0 ,  analysis]  -— > 

(HIGHEST  (CHANGE  (CANTUS-1))) 

sinca  (HIGHER  [HIGHEST  (CHANGE  CANTUS-1)]  [HIGHEST  CANTUS-1]) 


These  transformations  are  invalid  if  S  is  contracting,  eg.,  if  CANTUS  - 1  is  being  shortened. 


6.6.2.  Monotonic  and  Injective  Properties  of  Domain  Concepts 

Another  kind  of  knowledge  involves  certain  mathematical  properties  of  functions. 

6.6.2. 1  Monotonicity 

The  concept  of  a  function  monotonic  with  respect  to  an  ordering  is  illustrated  by  the  conditions  for 
the  validity  of 

RULE30:  (R  [f  S]  [f  S’])  ->  T  if  (subset  S  S’),  where  R  is  transitive 

RL  LF30  assumes  that  (subset  S  S')  implies  (R  [f  S]  [f  S')),  Le..  that  f  is  some  kind  of  measure 

relative  to  the  ordering  R  and  is  monotonic  with  respect  to  the  subset  relation  (the  measure  of  a  set  is 

an  upper  bound  on  the  measure  of  any  of  its  subsets).  The  use  of  RUI.E30  in  DER1V13  depends  on 

knowing  this  monotonicity  relationship  for  R  =  SUBSET  and  f  =  INTERVALS-OF,  Le.,  that  a 

subsequence  of  a  cantus  contains  a  subset  of  its  intervals: 

(SUBSET  [INTERVALS-OF  PR00F.CT1]  [INTERVALS-OF  ...]) 

13:23  ---  [REDUCE  by  RULE30]  ---> 

(SUBSET  PR0JECT1  .  .  . ) 

(Note  that  SU8SET  is  used  ambiguously  to  mean  both  "subset”  and  “subsequence.")  The 
monotonicity  relationship  also  holds  for  R  =  *<  and  f  =  RANGE.  Le..  the  range  of  a  subsequence  is  at 
most  the  range  of  the  cantus: 
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(=<  [RANGE  PROJECT  1  ]  [RANGE  ...]) 
13:46  ---  [REDUCE  by  RULE30]  ---3 
(SU8SET  PROJECT  1  .  . . ) 


Monotonicity  holds  for  R  =  =<  and  f  =  #,  ie.,  a  set  is  at  least  as  big  as  any  subset  of  it: 

(=<  [#  (SET-OF  X3  PROJECT  1  (=  X3  CLIMAX1))] 

[#  (SET-OF  X4  ...  (=  X4  CLIMAX1))]) 

13:96  ---  TREDUCE  by  RULE30]  ---> 

( SU8SET  (SET-OF  X3  PROJECT1  (=  X3  CLIMAX1)) 

(SET-OF  X4  ....  (  =  X4  CLIMAX  1 ) ) ) 


6.6. 2. 1  Injectiveness 


The  concept  of  an  injective  function  is  important  in  analyzing  the  validity  of 
RULf'FO:  (project  f (Jiff  S  S'))  ->  (Jiff  [project  f  S]  [project  f  S']) 


’['his  rule  preserves  semantic  equivalence  provided  the  condition  i(S-S')  =  RS)  -  f{$')  holds.  For 

example,  consider  the  transformation 

(PROJECT  HAND  (DIFF  (PLAYERS)  (SET  ME))) 

4:12  ---  [DISTRIBUTE  by  RULE i 70]  ---> 

(DIFF  [PROJECT  HAND  (PLAYERS)]  [PROJECT  HAND  (SET  ME)]) 


The  validity  of  this  transformation  depends  on  die  fact  that  HAND  is  injective  ( one-to-one),  i.e.,  each 
player  has  a  Jhtinct  hand.  The  condition  that  f  be  injective  is  a  sufficient  condition  for  preserving 
equivalence,  but  is  not  strictly  necessary.  RU1.E170  preserves  equivalence  except  when  S-S'  contains 
an  x  such  that  l]x)  is  in  f(ST.  In  other  words,  step  4.12  would  still  be  valid  even  if  the  rules  of  Hearts 
allowed  players  to  share  the  same  hand,  provided  no  other  player  in  (PLAYERS)  shared  (hand  me  ) . 


Another  rule  guaranteed  to  be  valid  for  injective  f  is 


RULH172:  (in  (fe)  (project  f  $))  ->  (in  c  S) 

(IN  (HAND  ME)  (PROJECT  HAND  (PLAYERS))) 

4:23  ---  [REDUCE  by  RULE  172]  ---> 

(IN  ME  (PLAYERS)) 

(IN  (CARD-OF  ME)  (PROJECT  CARD-OF  (PLAYERS))) 
5:23  ---  [REDUCE  by  RULE172]  ---> 

(IN  ME  (PLAYERS)) 


flic  latter  example  is  based  on  the  fact  that  CARD-OF  is  injective.  i.e..  two  players  can't  play  the 
same  card  in  the  same  trick,  or  for  that  matter  in  the  same  round.  (The  CARD-OF  function  implicitly 
depends  on  the  current  trick;  it  was  unnecessary  for  the  purposes  of  the  derivations  to  bother  making 


318 


§6.  Applications  of  Conceptual  Knowledge 


this  an  explicit  argument,  since  none  of  them  refer  to  cards  played  in  separate  tricks.)  RULE172  is 
valid  except  when  there  exists  an  x  not  in  S  such  that  tlx)  is  in  RS).  That  is,  steps  4:23  and  5  :23  are 
valid  even  if  HAND  and  CARD-OF  arc  not  injective,  so  long  as  nobody  in  (PLAYERS)  shares  a  hand 
with  or  plays  the  same  card  as  a  player  outside  the  game. 

Die  point  of  these  rather  detailed  examples  is  that  monotonicity  and  injectivity  arc  useful  in 
describing  sufficient  conditions  for  a  rule  to  be  valid,  but  necessary  conditions  for  validity  are  hard  to 
pinpoint. 

6.6.Z.3  Equivalence-preserving  Partial  Matching 

The  injective  property  is  closely  related  to  the  validity  of  partial  matching  as  an  equivalence- 
preserving  transformation.  For  example,  consider 

RULF43:  (R  [f  et ...  ej  [f  e^  ...  e^'])  ->  (and  [=  e^  e^'j ...  {=  cn  e^’j)  if  R  is  reflexive 

The  following  transformation  is  logically  valid  (preserves  equivalence)  because  hand  is  injective: 

(*  [HAND  PI]  [HAND  (QSO)]) 

3:55  -  [REDUCE  by  RULE43 ,  simplification]  - > 

(■  PI  (QSO) ) 

A  general  (sufficient)  condition  for  RULE43  to  be  valid  is  that 

f  is  injective  and  the  relation  R  coincides  with  the  equality  relation  on  the  range  of  j.'11 

The  second  condition  follows  from  the  requirement  that  the  rule's  left  side  imply  its  right  side: 

(R  [f  xt ...  xn]  (f  yt ...  yn])  =>  Xj  =  y(  A  ...  A  xfl  =  yn  [l.h.s.  =>  r.h.s.] 

By  the  substitution  property  of  equality: 

x.  =  v,  A  ...  A  x  =  y  =>  (f  x  ...  x  )  =  (f  y.  ...  y  ) 

1  l  n  1  n  v  1  or  v  1 1  1  or 

Thus 

(R  [f  Xi ...  xj  [f  y j ...  ynJ)  =>  (f  Xj ...  xn)  =  (f  yt ...  yn) 

l.e..  R  restricted  to  the  range  of  f  must  be  a  subset  of  the  equality  relation  if  RULE43  is  to  be  valid 
for  all  possible  values  of  Xj ...  xn  and  yt  ...  yn.  Since  R  is  reflexive  by  hypothesis.  R  restricted  to  the 
range  of  f  must  coincide  with  equality.  This  means  in  turn  that  f  is  injective,  Le„ 

ll 


1  owe  this  to  Jim  Saxe. 
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(fx1...xn)  =  (fy1...yn])=>x1  =  yiA...Axn=  yn 


This  is  easily  proved: 

(fXj  ...xn)  =  (fyt ...  ynJ)  =>  (R  (f  Xj  ...  xnJ  [f  y,  ...  yn])  [R  is  reflexivej 
(R  [f  Xj ...  xnJ  [f'y'j ...  ynJ)  =>  xl  =  yt  A  ...  A  xn  =  yn  [l.h.s.  =>  r.h.s.] 


The  condition  formulated  above  is  satisfied  for  R  =  =>,  f  =  MOVE: 

(=>  [MOVE  C4  (HAND  PI)  POT]  [MOVE  C3  (HAND  (QSO) )  L0C3]) 
3:52  ---  [SEDUCE  by  RULE43]  > 

(AND  [=  C4  C3]  [*  (HAND  PI)  (HAND  (QSO))]  [«=  POT  L0C3]) 


T he  function  MOVE  is  injective  because  movements  are  distinct  events  if  their  objects,  origins,  or 
destinations  differ.  In  fact,  every  action  concept  in  the  knowledge  base  is  injective  for  similar  reasons. 
’Hie  implication  relation  ->  coincides  with  equality  on  the  range  of  MOVE,  Le.,  the  set  of  movement 
events,  because  only  one  movement  can, occur  at  a  time  according  to  the  model  of  the  Hearts 
environment  represented  in  die  knowledge  base. 


The  same  condition  is  satisfied  for  R  =  DURING,  f  =  TAKE: 

(DURING  [TAKE  (TRICK-WINNER)  Cl]  [TAKE  ME  QS] ) 
5:12  ---  [REOUCE  by  RULE43]  ---> 

(AND  [»  (TRICK-WINNER)  ME]  [  =  Cl  QS]) 


The  function  take  is  injective  because  it's  an  action,  and  DURING  coincides  with  equality  on  the 
range  of  take.  i.e..  the  set  of  card-taking  events,  because  two  cards  can't  be  taken  simultaneously 
according  to  the  simplistic  model  of  the  domain. 


The  general  validity  condition  is  violated  for  R  =  o,  f  =  HAS  and  for  R  -  =>,  f  =  VOID: 


(  =  >  [HAS  PO  X2]  [HAS  PI  X2 ] ) 

9:33  ---  [REDUCE  by  RULE43]  -— > 

(AND  [=  PO  PI]  [=  X2  X2] ) 

(->  [VOID  PI  (SUIT-LED)]  [VOID  PO  SO]) 
11:11  ---  [REDUCE  by  RUIE43]  ---> 

(AND  [=  PI  PO]  [  =  (SUIT-LED)  SO]) 


The  relation  =>  doesn't  coincide  with  =  on  the  set  of  tmth  values,  since  NIL  =  >  T  hut  nil  *  T.  Nor 
are  has  and  VOID  injective:  they  can  map  different  combinations  of  arguments  to  the  same  tmth 
value.  Since  both  are  fluents,  the  test  for  injectivencss  is  somewhat  weaker:  a  fluent  is  injective  if  it 
doesn't  map  different  combinations  of  arguments  to  the  same  value  at  the  same  point  in  time,  has 
and  VO  10  fail  even  this  weaker  property.  In  fact,  in  both  examples  one  can  describe  situations  m 
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which  the  first  expression  is  true  and  the  second  is  false.  For  instance,  if  player  P0  doesn't  have  card 
X2,  then  {=>  [HAS  P0  X2]  [HAS  PI  X2])  is  vacuously  true  for  any  PI.  The  situation  needn’t 
involve  vacuously  true  implication;  one  can  imagine  situations  where  player  Pi’s  being  void  in 
(SUIT-LED)  implies  that  another  player  P0  is  void  in  SO  (e.g„  if  one  card  in  (SUIT-LED)  and 
another  in  suit  SO  arc  the  only  cards  still  out  after  the  last  trick  of  a  three-player  game  is  led). 

In  short,  not  only  is  the  general  (sufficient)  condition  violated  in  each  case,  but  the  uansformation 
actually  produces  an  expression  that  means  something  different  from  the  original  one.  Nonetheless, 
both  9:33  and  11:11  make  heuristic  sense;  they  contribute  to  the  construction  of  operational 
solutions.  One  explanation  of  this  apparent  paradox  is  drat  the  connective  =>  actually  denotes  some 
kind  of  relevant  implication  stronger  than  predicate  calculus  implication  (§5.9.2.2.1).  Another 
explanation  is  that  the  transformations  arc  heuristically  valid  because  they  preserve  semantic 
equivalence  in  all  but  a  few  perverse  situations  (§5.3.3). 

6.6.2.4  Soundness 

However,  a  much  simpler  explanation  is  that  in  both  cases  the  transformation  is  part  of  an  effort  to 
find  a  sufficient  condition  for  a  given  expression.  In  DER1V9,  die  problem  is  to  prove  that  all  of 
( CARDS- IN-hand  P0)  are  OUT;  in  DERIVU,  to  find  a  sufficient  condition  for  (VOID  P0  SO). 
Since  the  right  side  of  RULE43  implies  the  left  side,  it  is  guaranteed  to  be  logically  sound,  and 
therefore  semantically  appropriate  in  constructing  a  proof  or  in  finding  a  sufficient  condition.  A 
transformation  is  sound  if  it  never  transforms  falsehood  into  truth.  Thus  a  sequence  of  sound 
transformations  that  reduce  a  proposition  to  T  constitutes  a  proof  of  it. 

6.6.2.5  Problem-solving  Goal  as  an  Implicit  Rule  Condition 

This  example  shows  how  the  applicability  of  a  transformation  can  depend  not  only  on  the 
expression  to  be  transformed,  but  also  on  the  purpose  of  the  transformation  relative  to  die  current 
problem-solving  goal.  If  the  goal  is  to  reduce  a  problem  to  a  simpler  but  equivalent  one,  the 
transformation  must  be  valid',  if  the  goal  is  to  reduce  a  proposition  to  a  simpler  sufficient  condition  or 
to  prove  it  lie.,  reduce  it  to  T),  the  transformation  need  only  be  sound. 
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6.6.3.  Knowledge  about  Distinct  Entities 

A  basic  assumption  ofl'OO's  knowledge  representation  is  that 
Distinct  constants  denote  distinct  entities. 

In  DF.R1V3,  this  assumption  reflects  die  fact  that  spades  and  hearts  are  distinct  suits: 

( NEQ  S  H) 

3:31  ---  [COMPUTE  by  RULE236]  ---> 

T 

The  idea  of  a  collection  of  distinct  objects  is  important  in 
RL1.E288:  (d  (collection  c, ...  cn))  ->  n 

RULH2S8  is  only  valid  when  Cj  ...  en  represent  distinct  entities.  The  distinctness  property  figures 
as  an  invariant  in 

RULE171:  (project  f  (set  et ...  en))  ->  (set  (fe.) ...  ( f  cn)) 

RULE171  preserves  the  distinctness  property,  i.e.,  produces  a  list  of  expressions  denoting  distinct 
entities  when  e;  ...  en  is  such  a  list,  unless  (f  e)  =  (f  e.)  for  some  c  and  e.  in  e,  ...  en  where  i  *  j.  \ 
sufficient  condition  for  RULE171  to  preserve  distinctness  is  that  f  be  injective. 

6.6.4.  Knowledge  about  Logical  Connectives 

Several  of  roo’s  miles  transform  expressions  by  moving  logical  connectives  such  as  quantifiers  or 
implication.  It  appears  difficult  to  express  general  conditions  for  the  validity  of  such  transformations 
in  terms  of  easily  recognisable  properties  of  a  task  domain.  ie„  to  characterize  the  class  of  expressions 
for  which  they  preserve  semantic  equivalence.  The  apparent  reason  for  this  difficulty  is  that  the 
transformations  arc  expressed  in  structural  terms  (§5.10),  while  validity  is  a  semantic  property. 

For  example,  consider  the  function  transposition  mile  (§5.10.1) 

RULE58:  (during  [each  x  S  FJ  A)  ->  (exists  x  S  (during  Fx  A)) 


RUI.F58  produces  a  valid  (equivalence-preserving)  transformation  in  DFRIV5: 


322 


§6.  Applications  of  Conceptual  Knowledge 


(DURING  [EACH  Cl  (CARDS-PLAYED)  (TAKE  (TRICK-WINNER)  Cl)] 
[TAKE  ME  QS]) 

5:11  ---  [by  RULE58]  ---> 

(EXISTS  Cl  (CARDS-PLAYED) 

(DURING  [TAKE  (TRICK-WINNER)  Cl]  [TAKE  ME  QS])) 


This  transformation  is  valid  since  the  event  (TAKE  ME  QS)  can't  span  more  than  one  event 

(TAKE  (TRICK-WINNER)  Cl).  However,  RULE58  can  also  produce  the  transformation 

(DURING  [EACH  Cl  (CAROS-PLAYED)  (TAKE  (TRICK-WINNER)  Cl)] 

[EACH  Cl  (CARDS-PLAYED)  (TAKE  (TRICK-WINNER)  Cl)]) 

---  [by  RULE58]  ---> 

(EXISTS  Cl  (CAROS-PLAYED) 

(DURING  [TAKE  ( TR ICK-WI NNER )  Cl] 

[EACH  Cl  (CARDS-PLAYED)  (TAKE  (TRICK-WINNER)  Cl)])) 


This  transformation  is  obviously  invalid,  since  it  transforms  truth  to  falsehood. 


It  is  not  clear  how  to  characterize  concisely  the  class  of  expressions  for  which  RULE58  preserves 
equivalence.  Since  the  right  side  implies  the  left,  the  validity  condition  reduces  to  the  requirement 
(during  [each  x  S  E  ]  A)  =>  (exists  x  S  (during  Ex  A)).  One  can  formulate  sufficient  conditions  for 
validity:  RULE58  preserves  equivalence  if  events  of  type  A  can’t  span  more  than  one  event  of  type 
E.  and  can  always  be  used  in  derivations  of  the  form  Pt  =>  ...  =>  Pn_  However,  there  appears  to  be 
no  obvious  easy- to- test  necessary  and  sufficient  condition  for  the  validity  of  RULES8. 

This  problem  is  even  worse  for  other  rules  that  move  quantifiers  and  implication  connectives: 

RULE192:  ( =  [Q  x  S  Px]  [Q  y  S  Ry])  ->  ( =  Py  Ry),  where  y  is  implicitly  universally  quantified 

RULE220:  (  =  >  C  [Q  x  S  PxD  ->  (Q  x  S  [=>  C  P^]) 

RUI.E224:  ( =  >  [and  Cj ...  C  ...  CJ  [P  ...])  ->  ( =  >  C  [P  ...])  if  P  occurs  in  C 

RULE225:  ( =  >  [or ...  C  ...]  [P  ...])  ->  (and  [not  (or  ...)|  [  =  >  C  (P  ...)])  if  P  occurs  in  C 

RULE226:  (  =  >[=>  R  C]  [P ...])  ->  (and  R  [  =  >  C  (P ...)])  if  P  occurs  in  C 

RULE321:  ( =  >  [P  ...]  [and  C1 ...  C ...  CnJ)  ->  (and  [=>  (P ...)  C]  C1 ...  Cn)  if  P  occurs  in  C 

RULH322:  (  =  >  [P  c£ ...  cn]  [exists  x  S  (Pe^  ...  cn’)[)  ->  (and  [in  x  SI  [=  Cj  e^] ...  [=  cncn’]), 
where  x  is  implicitly  existentially  quantified  -  combines  RULE 2 20  and  partial  matching 

RULE329:  (P ...  (Q  x  S  RJ  ...)  ->  (Q  x  S  [P  ...  Rx ...])  -  subsumes  RULE220 

Some  of  these  (e.g..  RULE192)  arc  logically  sound,  but  the  logical  status  of  the  others  is  unclear. 
For  example,  if  P  quantifies  over  a  second  variable  y  appearing  in  Rx,  RUI.E329  can  transform  the 
assertion  that  every  integer  is  less  than  some  other  into  the  claim  that  a  greatest  integer  exists: 
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(FORALL  Y  (INTEGERS)  (EXISTS  X  (INTEGERS)  (<  Y  X))) 
---  [by  RULE329]  ---> 

(EXISTS  X  (INTEGERS)  (FORALL  Y  (INTEGERS)  (<  Y  X))) 


RUI.E329  transforms  truth  into  falsehood  and  vice  versa  by  transposing  not  with  a  quantifier: 

(NOT  (FORALL  X  (INTEGERS)  (=  X  0))) 

---  [by  RULE329]  ---> 

(FORALL  X  (INTEGERS)  (NOT  (=  X  0))) 

(NOT  (EXISTS  X  (INTEGERS)  (=  X  0))) 

[by  RULE329]  ---> 

(EXISTS  X  (INTEGERS)  (NOT  ( =  X  0))) 


In  general,  the  semantic  effect,  of  restructuring  an  implication  or  quantified  statement  depends  on 
the  individual  expression,  and  there  is  no  apparent  easily  tested  criterion  that  characterizes  the  class  of 
expressions  for  which  such  a  transformation  preserves  semantic  equivalence. 

A  heuristic  approach  to  this  problem  is  to  use  such  transformations  freely  and  see  if  they  produce 
effectiv  e  solutions.  If  an  expectation  raised  by  the  solution  is  subsequently  violated  in  an  actual  task 
situation,  and  the  error  is  traced  back  to  die  transformation,  tire  solution  can  be  revised  or  replaced. 
The  paradigm  of  learning  based  on  analysis  of  violated  expectations  is  discussed  in  {Hayes- Roth  Sib], 


6.7.  Applications  of  Conceptual  Knowledge:  Summary 

Some  of  the  conceptual  knowledge  used  in  the  derivations  is  explicitly  encoded  in  TOO  as 
definitions  and  semantic  relations:  some  is  simulated  by  rules  or  assumptions;  and  some  knowledge 
about  when  transformations  arc  semantically  appropriate  is  missing.  Thus  conceptual  knowledge 
used  in  operationalization  forms  a  taxonomy  based  on  how  (and  whether)  it’s  encoded  in  t  oo: 

1.  Encoded  knowledge  (§1.3) 

a.  Explicitly  encoded  knowledge  (§1.3) 

i.  Concept  definitions  (§1.3.1) 

ii.  Semantic  relations  (§1.3.2) 

1.  ls-a  hierarchy  (§  1.3.2. 1) 

2.  Auributc-valuc  pairs  (§1. 3.2.2) 

b.  Knowledge  base  as  implicit  model  of  domain  (§6.4)  --  definitions  as  assertions  (§6.4.3) 


i.  Wcll-dcfmedncss  assumption  (§6.4.1) 
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1.  Embedded  assertions  (§6.4.2) 

ii.  Distinct-constant  assumption  (§6.6.3) 
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2.  Simulated  knowledge 

a.  Fact  rules  (§1.3.3) 

i.  Types  (§1. 3.3.1) 

ii.  Partitions  (§1.3.3.2) 

iii.  Features  (§  1.3.3.3) 

iv.  Deductions  (§  1.3.3.4) 

b.  Explicit  assumptions  made  in  derivations  (§6.4.4) 

3.  Missing  knowledge  corresponding  to  implicit  rule  conditions  (§6.6) 

a.  Runtime  capabilities  (§6.6.1) 

i.  Immutable  conditions  (§6.6.1. 1) 

ii.  Processes  (§6.6.1.3) 

iii.  Evaluabiiity  (§6.6. 1.2) 

b.  Mathematical  properties  of  and  relations  between  concepts  (§6.6.2) 

i.  Monotonicity  (§6.6.2.1) 

ii.  Injectiveness  (§6.6.2.2) 

c.  Rule  properties  relative  to  operationalization  goals  (§6.6.2.5) 

i.  Preserve  semantic  equivalence  (§6.6.2.3) 

ii.  Transform  to  sufficient  condition  (soundness)  (§6.6. 2.4) 

iii.  Preserve  distinctness  of  enumeration  (§6.6.3) 

d.  Effect  of  moving  logical  connectives  (§6.6.4) 

The  conceptual  knowledge  encoded  in  FOO  is  used  in  various  ways  (§6).  An  obvious  one.  and  in 
fact  the  most  common,  is  to  plug  in  the  definition  of  a  concept  (§6.2).  However,  the  more  interesting 
applications  of  conceptual  knowledge  arc  those  that  achieve  useful  results  without  expanding  the 
problem  down  to  the  lowest  level  of  detail.  For  instance,  long  chains  of  reasoning  can  be  skipped  by 
exploiting  stored  semantic  relations  between  concepts  (§1.3.2).  such  as  homomorphic 
mappings  (§6.1.2).  This  is  facilitated  by  a  rule  matcher  that  applies  general  rules  to  (domain-)  specific 
problems  by  searching  through  an  is-a  hierarchy  (§6.1).  Other  methods  search  the  knowledge  base  of 
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concept  definitions  for  concepts  of  a  particular  form  (§6.5).  This  creates  the  potential  for  extending 
the  range  of  derivable  operationalizations  simply  by  defining  a  new  concept  (§6.5.5). 

Applications  of  conceptual  knowledge  in  COO  fit  into  a  taxonomy: 

1.  Translation  (§5.8) 

a.  Elaboration  --  expand  definition  (§6.2) 

i.  Map  problem  to  general  method  (§5.8.2) 

ii.  Split  problem  into  subprobleins  (§5.7.4) 

b.  Recognition  --  identify  known  concept  bv  matching  (§6.3)  or  analysis  (§6.3.2) 

i.  Find  action  w  ith  specified  effect  (§2,4) 

ii.  Find  learned  methods  indexed  under  concept  (§6.3.1) 

2.  Search  through  concept  definitions  (§6.5) 

a.  Intersection  search  based  on  closure  assumption  (§6.5.1) 

b.  Plausible  generation  based  on  useful-concept  assumption  (§6.5.2) 

i.  Find  sufficient  condition  (§6.5.2) 

ii.  Find  action  with  specified  effect  (§6.5.3) 

iii.  Find  necessary  condition  (§6.5.4) 

3.  Use  semantic  relations  to  connect  genera!  and  specific  concepts  (§6.1) 

a.  Exploit  special  cases  (§6.1.1) 

b.  Apply  homotuorphisms  (§6.1.2) 

c.  Delete  identity  elements  (§6.1.3) 

d.  t  ranslate  between  related  adjectives  (§6.1.4) 

Most  of  FOO's  domain  knowledge  is  encoded  as  LISP  function  definitions  (§1.3.1).  Different  parts 
of  speech  correspond  to  functions  of  different  forms  (§1.3. 1.3).  Since  TOO  deals  only  with  well- 
formed  input,  its  knowledge  representation  lacks  features  like  slot  restrictions  (§1.3. 1.1)  designed  to 
facilitate  processes  of  disambiguation,  instantiation,  and  completion  that  deal  with  the  informality  of 
natural  language  (§8.2.1).  Such  features  were  simulated  by  rules  when  needed  (§1.3.3),  notably  in 
instantiating  missing  components  of  methods  (§2.3. 1.4)  (§3.3). 
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Chapter  7 

Rules  as  Operators  for  Means-End  Analysis 

As  we  have  seen,  analysis  is  the  glue  that  holds  the  operationalization  process  together:  it  makes 
the  connection  between  a  problem  stated  in  one  set  of  terms  and  a  method  stated  in  another. 
Consider  the  problem  of  automatically  choosing  which  rule  to  apply  at  each  point,  at  least  for  making 
these  sorts  of  connections  and  solving  the  subproblems  generated  by  die  higher-level 
operationalization  mediods.  An  obvious  approach  would  use  means- end  analysis  ("Mlf.A")  [Newell 
69]  to  guide  rule  selection.  What  knowledge  about  the  rules  is  required  to  use  diem  as  operators  in  a 
problem  reduction  mode  for  translating  expressions  to  a  desired  form?  For  example,  can  the  rules  be 
characterized  as  translating  between  abstract  regions  of  expressions  corresponding  to  different 
languages,  e.g.,  numbers,  sets,  quantifiers?  If  so.  could  a  rule  sequence  for  translating  an  expression 
from  one  region  to  another  be  found  by  an  intersection  search  through  an  abstracted  network  with 
nodes  for  the  regions  and  arcs  for  die  rules? 

(§7.3)  models  the  main  proof  ;n  DKRIV12  as  die  product  of  a  MBA  problem-solver  in  order  to 
explore  the  sorts  of  differences  and  goal  descriptions  that  might  be  needed.  As  an  aid  to 
understanding  diis  extended  example.  (§7.1)  defines  three  kinds  of  differences  betw  een  expressions, 
and  (§7.2)  illustrates  them  by  means  of  a  simple  example.  (§7.4)  summarizes  the  lessons  drawn  from 
the  examples. 


7.1.  Differences  between  Expressions 

To  get  an  idea  of  how  roo's  rules  might  be  used  as  operators.  1  tried  to  analyze  what  die  GPS-type 
differences  [Newell  60]  would  be  in  a  typical  analysis.  The  differences  in  die  example  include 
mismatches  between  current  and  desired  expression  (§7.1.1).  disagreement  between  two  sub¬ 
expressions  which  must  agree  in  order  to  match  a  rule  condition  (§7.1.2),  and  structural  differences 
between  a  current  expression  and  a  desired  expression  with  the  same  symbols  arranged 
differently  (§7.1.3). 
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7.1.1.  Corresponding  Symbols  Mismatch 

The  simplest  kind  of  difference  between  the  current  expression  (f ...)  and  a  desired  expression 
(g  ...)  is  when  f  *  g,  or  more  precisely,  the  condition  f  is-a  g  docs  not  hold.  A  rule  sequence  for 
eliminating  this  difference  may  be  found  by  searching  a  network  whose  nodes  are  the  top-most 
symbols  of  the  rule  left-  and  right-hand  sides,  and  whose  arcs  correspond  to  the  rules  in  the  obvious 
way.  Thus  a  rule  (f  ...)  ->  (g’ ...)  would  be  represented  in  the  network  by  the  arc  f  ->  g'.  The  search 
algorithm  must  also  allow  any  number  of  is-a  links.  For  instance,  if  f  is-a  f  and  g  is-a  g\  die  search 
would  retrieve  the  rule  (f  ...)  ->  (g’  ...)  as  a  candidate  for  reducing  die  difference  between  (f ...)  and 
(g...). 

The  network  representation  for  a  rule  of  the  form  (f  x.  ...  xk)  ->  (f  ...  yk)  is  more  complicated, 
since  such  a  rule  doesn’t  change  the  top-most  symbol  of  the  expression  to  which  it’s  applied.  Such  a 
rule  is  represented  as  several  arcs  x(  ->  y;.  If  x;  *  y(,  arcs  between  the  corresponding  unequal 
components  of  x.  and  y.  are  included,  and  so  forth.  These  arcs  represent  context-sensitive 
transformations,  Le..  transformations  x.  ->  y;  that  only  apply  when  x;  occurs  inside  an  expression  of 
the  form  (f  xt ...  xk).  An  example  of  a  rule  that  leaves  the  top-most  symbol  unchanged  is 

RULE161:  (Q  x  S  (P ...  (f  x) ...))  ->  (Q  y  (project  f  S)(P ...  y  ...» 

RULE161  transforms  a  quantified  expression  into  another  with  die  same  top-most  symbol  Q.  It 
would  be  represented  in  the  network  by  two  arcs.  The  arc  SET  ->  project  represents  the 
difference  between  S  and  (project  f  S),  and  die  arc  FUNCTION  ->  VARIABLE  represents  the 
difference  between  (f  x)  and  y. 

The  elaboration  rule  RULE124  and  the  recognition  rale  RULE123  would  have  to  be  treated 
specially  to  avoid  short-circuiting  the  search  mechanism.  For  example,  representing  RULE123  as 
ANY  ->  DEFINED  would  cause  it  to  be  suggested  as  a  one-arc  solution  to  almost  any  search  problem. 
To  avoid  diis  problem,  RULE123  could  be  represented  as  a  set  of  arcs  f ->  g  for  each  concept  f  whose 
definition  is  of  the  form  (lambda  (x.  ...  xn)  (g  ...)).  For  example,  these  arcs  would  include 
MOVE  ->  GET-CARD,  MOVE  ->  PLAY,  and  MOVE  ->  TAKE  corresponding  to  the  definitions 
GET-CARD  =  (LAMBDA  (P  C)  (MOVE  C  ?L0C  (HAND  P) ) ) 

PLAY  *  (LAMBDA  (P  C)  (MOVE  C  (HAND  P)  POT)) 

TAKE  *  (LAMBDA  (P  C)  (MOVE  C  POT  (PILE  P))) 

RULE124  would  be  represented  by  the  same  arcs  going  in  the  opposite  direction.  This  more 
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specific  encoding  would  make  it  possible  to  find  connections  between  concepts  related  by  their 
definitions  without  finding  spurious  shortcuts  between  other  concepts. 

7.1.2.  Internal  Disagreement 

Another  kind  of  difference  is  \iolation  of  an  agreement  condition  implied  by  the  occurrence  of  the 
same  variable  in  more  than  one  place  in  a  rule  condition.  Consider  an  expression  of  the  form 
( =  >  (f ...)  (g  ...)).  where  f  *  g.  It  violates  the  condition  f  =  g  required  to  satisfy  the  left-hand  side  of 
a  matching  rule  like 

RULH43:  (R  (f  x; ...  xn) (f  yt ...  yn))  ->  (and  (  =  Xj  ...  (=  xn  yn)) 

Eliminating  a  difference  of  this  kind  appeal's  to  require  rules  like 

To  express  (f ...)  and  (g  ,..)  in  common  terms,  expand  (f ...)  in  terms  of  (g  ...). 

A  search  procedure  for  this  rule  might  search  through  the  knowledge  base  of  concept  definitions  to 
see  if  f  were  defined  directly  or  indirectly  in  tenns  of  g.  roo  already  has  a  procedure  that  docs 
exactly  this  kind  of  search  for  other  reasons  (§5.6). 

7.1.3.  Structural  Differences 

Sometimes  one  can  find  a  path  from  a  sub- expression  of  die  current  expression  to  a  desired  form. 
Here  the  difference  is  one  of  non-adjacency.  Suppose  the  current  expression  is  (f  (g  ...  e  ...)),  die 
desired  form  is  (f  c'),  and  there  is  a  path  from  e  to  c'.  The  problem  is  that  e  is  not  adjacent  to  f.  A 
solution  may  be  to  bring  c  closer  to  f  by  applying  a  transposition  rule  (f  (g  ...))  ->  (g  (f ...)),  e.g., 

RUI.E329:  (!’ ...  (Q  x  S  Ex) ...)  ->  (Q  x  S  (P  ...  Kx  ...)) 

RU1-F329  moves  quantifier  Q  outside,  thereby  lifting  Ex  closer  to  P.  This  may  eventually  make  it 
possible  to  apply  a  rule  whose  left-hand  side  has  die  desired  form  (P  E).  In  general,  structural 
differences  can  be  eliminated  by  restructuring  rules  (§5.10). 
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7.2.  A  Simple  Example  of  Means-End  Analysis 

The  differences  and  the  techniques  for  reducing  diem  discussed  \n  (§7.1)  can  be  illustrated  by 
showing  how  they  could  be  used  to  translate  into  the  language  of  the  pigeon-hole  principle  the 
problem  of  deciding  whether  the  Queen  of  spades  is  out  (§5.8.1).  The  translation  begins  by 
successive  elaboration: 

(QS-OUT) 

4:1  ---  [ELABORATE  by  RULE  124]  ---> 

(OUT  QS ) 

4:2  ---  [ELABORATE  by  RULE124]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  QS)) 

(HAS  PI  QS) 

4:3  ---  [ELABORATE  by  RULE124]  ---> 

(AT  QS  (HANO  PI)) 

4:4  ---  [ELABORATE  by  RULE124]  ---> 

(  =  (LOC  QS)  (HAND  PI)) 

This  is  followed  by  a  change  of  variable  using 

RULE161:  <Q  x  S  [P ...  (f  x) ...])  ->  (Q  y  (project  f  S)  [P  ...  y  ...)) 

The  effect  is  to  restructure  the  quantification  (§5.10): 

(EXISTS  PI  (OPPONENTS  ME)  [=  (LOC  QS)  (HAND  PI)]) 

4:5  [transfar  HAND  by  RULE161]  - > 

(EXISTS  Y1  (PROJECT  HAND  (OPPONENTS  ME))  [=  (LOC  QS)  Yl]) 

The  equality,  quantified  over  hands  instead  of  players,  is  recognized  in  terms  of  set  membership: 

4:6  ---  [RECOGNIZE  by  RULE162]  ---> 

(IN  (LOC  QS)  (PROJECT  HAND  (OPPONENTS  ME))) 

The  recognition  is  performed  by 

RU1-E162:  (exists  x  S  ( =  e  x))  ->  (in  e  S) 

The  resulting  expression  matches  the  problem  statement  for  the  pigeon-hole  principle  (§2.2): 
RULE169:  (in  (f ...)  S)  ->  (not  (in  (f ...)  (diff  (Range  0  S))) 

Suppose  the  initial  goal  is  to  reformulate  (QS-OUT)  in  the  form  (IN  .  . . )  so  that  the  pigeon-hole 
principle  can  be  applied.  (The  interesting  problem  of  how  this  goal  might  be  adopted  in  the  first 
place  is  outside  the  scope  of  this  discussion  (§-4.2.2. 1 )  (§8.1.1).)  How  might  the  transformation 
sequence  4 : 1-6  be  generated  automatically? 
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First,  die  mismatch  between  the  top-level  symbols  QS-OUT  and  IN  suggests  searching  the  network 
representation  of  die  rules  fora  path  between  them  (§7.1.1).  Such  a  path  exists: 

QS-OUT  - -  RULE  1 24  - OUT  - -RULE  124 -- >  EXISTS  --RULE162-->  IN 

1'his  path  constitutes  a  top-!e\el  plan  for  translating  (QS-OUT)  into  die  desired  form.  The  first  two 
steps  of  this  plan  are  immediately  executable,  and  correspond  to  4:1-2. 

Now  a  snag  develops:  die  expression  (EXISTS  Pi  (OPPONENTS  ME)  (HAS  PI  QS))  docs  not 
match  die  left-hand  side  of  the  next  rule  in  the  plan,  namely 

RLT.E162:  (exists  x  S  ( =  ex))  ->  (in  e  S) 

As  before,  die  mismatch  between  the  corresponding  symbols  has  and  -  suggests  finding  a  path 
between  them.  Such  a  path  exists: 

HAS  - -RULE  124 - ->  AT  --RULE124--5  = 

Steps  4:3-4  correspond  to  the  rule  applications  indicated  by  this  path. 

The  resulting  expression  (EXISTS  PI  (OPPONENTS  ME)  (=  (LOC  QS)  (HAND  Pi )))  still  does 
not  match  the  left-hand  side  of  RUI.E162,  hut  the  mismatch  is  now  of  a  different  nature:  internal 
disagreement  (§7.1.2)  between  the  quantifier  variable  Pi  and  the  second  argument  (HAND  PI)  of  the 
quantified  equality,  both  of  which  correspond  to  x  in  RUI.F162.  However,  this  can  be  viewed  as  a 
staictural  difference,  since  the  desired  argument  ?  i  occurs  as  a  sub-expression  of  the  actual  argument 
(HAND  Pi)  (§7.1.3).  One  way  to  move  the  function  hand  uut  of  the  equality  is  to  transfer  it  (§5.10.2) 
to  another  component  of  the  expression  containing  it.  This  is  done  at  step  4:5  by  a  restructuring 
rule: 

RULI-161:  (Q  x  S  fP ...  (f  x) ...])  ->  (Q  y  (project  fS)  [P  ...  >  ...]) 

RULE161  transfers  f  from  a  quantified  condition  to  the  component  describing  die  scope  of 
quantification.  Here  f  =  HAND. 

This  produces  (EXISTS  PI  (PROJECi  HAND  (OPPONENTS  ME))  [=  (LOC  QS)  Y  l  ]).  enabling 
die  top-level  plan  to  be  completed  by  applying  RULK162  at  step  4 : 6. 

The  resulting  expression  matches  the  left-hand  side  of  RU1.F1H9.  so  die  initial  goal  of  translating 
(QS-OUT)  into  die  language  of  the  pigeon-hole  rule  has  been  achieved.  The  point  of  dits  example 


r 
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was  to  show  how  a  sequence  of  ailcs  applied  in  DERIV4  could  have  been  chosen  automatically  using 

means-end  analysis.  The  hierarchical  plan  underlying  this  sequence  is  summarized  below.  The 

underlined  prerequisites  of  steps  in  the  plan  are  subgoals  to  be  satisfied  at  a  lower  level  of  detail.  The 

top-level  goal  is  to  apply  RULE169  to  the  expression  (QS-QUT). 

RULE  169 :  IN  (f  x)  S  ->  apply  pigeon-hole  principle 

4:1  RULE124 :  QS-OUT  ->  OUT 

4:2  RULE124 :  OUT  ->  EXISTS 

4:6  RULE  162 :  EXISTS  x  S  (  =  e  x)  ->  IN  e  S 

4:3  RULE  124 :  HAS  ->  AT 

4:4  RULE  124 :  AT  ->  = 

4:5  RULE  161 :  0  x  S  {=  e  (f  x))  ->  transfer  f  to  S 


7.3.  An  Extended  Example  of  Means-End  Analysis 

This  section  presents  a  MEA  model  of  the  main  proof  in  DER1V12  (§2.4.2).  i.e.,  tries  to  explain 
how  the  sequence  of  rules  used  could  have  been  determined  by  means-end  analysis.  In  the  process,  it 
makes  several  observations  about  the  kinds  of  information  a  means-end  analysis  component  would 
need  to  know  about  the  rules,  and  how  a  substantial  portion  of  it  could  be  encoded  in  a  network  and 
retrieved  by  intersection  search. 

At  each  step  in  the  example,  the  simulated  problem-solver  has  a  current  expression  and  a  desired 

expression ,  cither  of  which  may  be  a  somewhat  abstracted  description  of  a  class  of  expressions.  The 

difference  between  the  two  is  used  to  suggest  a  rule,  sequence  of  rules,  or  abstract  operation  (e.g„ 

lifting  a  sub-expression)  to  reduce  or  eliminate  the  difference.  If  a  proposed  rule  is  not  immediately 

applicable,  the  problem-solver  establishes  a  subgoal  whose  desired  expression  is  the  left-hand  side  of 

the  rule.  Once  the  subgoal  is  achieved,  the  rule  is  applied.  The  example  derivation  exhibits  a  rather 

nested  structure;  the  first  rule  suggested  is  not  applied  until  the  last  step,  and  the  basic  plan  (rule 

sequence)  for  most  of  the  derivation  is  created  before  the  first  step  is  actually  executed.  The  note- 

diffcrence/fmd-rule/apply-rule  cycle  is  shown  in  the  notation; 

/  <current  expression) 

\  Cdesired  expression) 

Find  <rule>:  <lhs>  ->  <rbs> 

Cunsatisfied  Ihs  or  rule  condition) 

<subgoal  . . . > 

<current  expression) 

d:n  —  [<tranformation  type)  by  <rule>]  — ) 

<n8w  expression) 


« 


The  assumed  goal  at  the  beginning  of  the  example  is  to  apply 
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RULH234:  P  ->  (was-during  (current  A)  P)  if  (not  (during  (A)  (undo  P))) 

(As  in  (§7.2).  the  origin  of  this  goal  is  beyond  the  concern  of  the  example.)  Here  P  = 
(VOID  PO  SO),  A  =  ROUND-IN-PROGRESS.  Thus  the  initial  expression  is 

(NOT  (DURING  (ROUND-IN-PROGRESS)  (UNDO  (VOID  PO  SO)))) 

The  goal  is  to  verify  this  condition,  i.e..  transform  it  to  T.  This  is  represented  by  die  difference 

/  (NOT  (DURING  ( ROUND- IN-PROGRESS )  (UNDO  (VOID  PO  SO)))) 

\  T 


Hie  initial  expression  is  a  negated  condition,  while  die  desired  form  is  the  truth  constant: 

/  NOT 
\  T 


Thus  the  top-level  difference  between  the  two  is  a  mismatch  between  die  corresponding  symbols 
NOT  and  T  (§7.1.1).  An  intersection  search  through  the  abstract  rule  network  described  earlier  would 
find  die  arc  computable  ->  CONSTANT  corresponding  to 

RULE236:  (fcJ ...  cn)  ->  c, 

where  c  is  die  result  of  applying  the  computable  function  f  to  the  constant  arguments  ...  cn 

RCLE236  transforms  a  computable  function  of  constant  arguments  into  a  constant.  The  search 
path  would  include  the  arcs  not  is -a  computable  and  T  is -a  constant: 

not  T 

is-a  is-a 

COMPUTABLE  --RULE2o5-->  CONSTANT 

1'hus  the  simple  network  representation  contains  enough  information  to  suggest  using  RULF.236: 

Find  RULE235 :  COMPUTABLE  ->  CONSTANT 
RULE236  condition:  arguments  must  be  constants 

RL'l.F.236  requires  that  all  die  arguments  be  constants.  The  single  argument  to  NOT  in  the  initial 
expression  is  not  a  constant.  This  mismatch  must  be  fixed  before  RL1.E236  can  be  applied. 

/  (DURING  ( ROUND- IN -PROGRESS) 

/  (UNOO  (VOID  PO  SO))) 

\  CONSTANT 


An  intersection  search  between  DURING  and  <eonstant>  would  find  the  path 
OURING  --RULE57-->  NIL  --is-a-->  CONSTANT 
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The  first  arc  of  this  path  represents 

RULE57:  (during  s  e)  ->  nil  if  s  and  e  have  no  sub-events  in  common 

The  second  arc  simply  represents  the  fact  that  NIL  is  a  constant. 

Find  RULE57 :  DURING  ->  NIL 

RULE57  condition:  args  refer  to  known  actions 

In  order  to  compute  the  sub-events  of  s  and  e.  they  must  be  expressed  in  terms  of  known  action 

concepts.  ROUND- IN- PROGRESS  is  such  a  concept,  but  UNOO  is  not.  This  is  a  mismatch. 

/  (UNDO  (VOID  PO  SO)) 

\  ( . . .  KNOWN-ACTION  . . . ) 


An  intersection  search  between  UNDO  and  KNOWN-ACTION  would  find  the  following  path: 

KNOWN-ACTION 

is-a 

UNDO  --RUL£377-->  CAUSE  — RULE358-->  MOVE  --RULE123-->  DEFINED 

The  rules  represented  by  this  path  are: 

RULE377:  (undo  (not  P)) ->  (cause  P) 

RULF.358:  (cause  (at  obj  loc))  ->  (move  obj  loc’  loc),  where  loc’  is  the  previous  location  of  obj 

RULE123:  e  ->  (f  e1 ...  en)  if  fis  defined  as  (lambda  (x1 ...  xn)e’) 
and  e  is  the  result  of  substituting  eL ...  en  for  xf ...  xn  throughout  e’ 

RUI.E377  and  RULE358  are  represented  by  the  respective  arcs  UNDO  ->  CAUSE  and 
CAUSE  ->  MOVE,  while  RULE123  is  represented  by  a  set  of  arcs  (§7.1.1).  This  set  includes  the  arcs 
MOVE  ->  GET-CARD,  MOVE  ->  PLAY,  and  MOVE  ->  TAKE  corresponding  to  the  definitions 
GET-CARD  =  (LAMBDA  (P  C)  (MOVE  C  ?L0C  (HAND  P))) 

PLAY  =  (LAMBDA  (P  C)  (MOVE  C  (HAND  P)  POT)) 

TAKE  *  (LAMBDA  (P  C)  (MOVE  C  POT  (PILE  P))) 

Actually,  these  concepts  define  three  different  paths  from  UNDO  to  KNOWN- ACT  ION: 


UNOO  --. 

,  .  --> 

MOVE 

--RULE123- 

-> 

GET- 

CARD  is-a  KNOWN-ACTION 

UNOO  --. 

MOVE 

--RULE123- 

-> 

PLAY 

is-a  KNOWN-ACTION 

UNOO  --. 

.  .--> 

MOVE 

--RULE123- 

-> 

TAKE 

is-a  KNOWN-ACTION 

However,  all  three  paths  correspond  to  the  same  rule  sequence: 
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Find  RULE377-RULE358-RULE123 


Iliis  rule  sequence  gives  a  high-level  plan  for  reformulating  the  current  expression  in  terms  of  a 
known  action.  Execution  of  the  plan  begins  b\  trying  to  apply  the  first  rule  in  die  sequence: 

RULE377  lhs :  (UNDO  (NOT  . . . ) ) 


The  current  expression  (UNDO  (VOID  .  .  . ))  mismatches  the  left  side  of 
RULE377:  (undo  (not  P))  ->  (cause  P) 

/  VOID 
\  NOT 

Find  RULE  124:  VOID  ->  NOT 


An  intersection  search  would  rind  die  arc  VOID  --RULE  1 24-  ->  NOT  based  on  die  definition 
VOID  =  (LAMBDA  (P  S) 

(NOT  (EXISTS  C  ( CARDS  -  IN-HAND  P)  (IM-SUIT  C  S)))) 


The  reasoning  up  to  this  point  has  generated  a  hierarchical  partial  plan  for  proving 

(NOT  (DURING  (ROUND-IN-PROGRESS)  (UNDO  (VOID  PO  SO)))) 


Lower-level  plan  steps  satisfy  prerequisites  (underlined  below)  for  higher-level  steps: 

Prove  (NOT  (DURING  (ROUND-IN-PROGRESS)  (UNDO  (VOID  PO  SO)))) 
RULE236 :  NOT  CONSTANT  ->  T 

RULE57 :  DURING  KNOWN -ACT ION  ->  NIL 
RULE377 :  UNDO  NOT  ->  CAUSE 
•  RULE  1 24 :  VOIO  ->  NOT 
RULE358 :  CAUSE  ->  MOVE 
RULE  123:  MOVE  ->  KNOWN-ACTION 


The  starred  step  is  immediately  executable,  and  constitutes  the  first  actual  step  of  die  proof: 

(VOID  PO  SO) 

12:2  ---  [ELABORATE  by  RULEI24 J  ---> 

(NOT  (EXISTS  Cl 

(CAROS- IN-HAND  PO) 
(IN-SUIT  Cl  SO))) 


This  satisfies  die  precondition  of  RULH377,  so  apply  it: 

(UNDO  (NOT  (EXISTS  Cl 

(CARDS- IN-HAND  PO) 
(IN-SUIT  Cl  SO)))) 

12:3  ---  [RECOGNIZE  by  RULE377]  ---> 

(CAUSE  (EXISTS  Cl  (CAROS- IN-HAND  PO) 
(IN-SUIT  Cl  SO))) 
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The  next  rule  in  the  3-rulc  sequence  found  earlier  is 

RULE358:  (cause  (at  obj  loc))  ->  (move  obj  loc’  loc),  where  loc’  is  the  previous  location  of  obj 

The  left  side  of  RULE358  doesn't  match  the  current  expression: 

(CAUSE  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))) 

RULE358  lh$:  (CAUSE  (AT  ?0BJ  ?10C)) 

/  EXISTS 
\  AT 

Searching  for  a  path  from  EXISTS  to  AT  would  lead  to  a  dead  end.  More  context  is  needed: 

/  (CAUSE  (EXISTS  Cl  (CARDS-IN-HAND  PO) 

/  (IN-SUIT  Cl  SO))) 

\  (CAUSE  (AT  ?0B J  ?L0C)) 

Although  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO))  and  (AT  ?0BJ  ?L0C) 

mismatch,  they  arc  related  in  that  the  definition  of  CARDS-IN-HAND  indirectly  mentions  at: 

CARDS-IN-HAND 
defined  as 

(SET-OF  C  (CARDS)  (HAS  P  C))  --contains-->  HAS  --RULEl24-->  AT 

This  connection  could  be  discovered  by  an  intersection  search  based  on  the  definitions 
CARDS-IN-HAND  *  (LAMBDA  (P)  (SET-OF  C  (CARDS)  (HAS  P  C))) 

HAS  =  (LAMBDA  (P  C)  (AT  C  (HAND  P))) 

Such  a  search  has  a  higher  branching  factor  than  the  kind  described  earlier,  since  it  propagates 
from  the  node  for  f  ;o  all  the  functions  used  in  the  definition  of  f,  not  just  the  top-most  one.  Note 
that  the  network  for  tins  search  includes  a  node  for  each  concept  plus  another  for  its  definition. 

The  semantic  connection  between  CARDS-IN-HAND  and  AT  suggests  using  fiinction 
transposition (§5.10.1)  to  embed  CMSZ  next  to  (CARDS-IN-HAND  PO): 

Embed  CAUSE  next  to  CARDS-IN-HAND 


4 


One  of  FOO's  fiinction  transposition  rules  is 

RULE329:  (P ...  (Q  x  S  Ex) ...)  ->  (Q  x  S  (P  ...  Ex  ...))  --  embed  P  closer  to  Ex 

Why  choose  RULE329  over  other  transposition  rules?  The  left  side  of  the  chosen  rule  should 
resemble  the  current  expression,  and  its  effect  should  match  the  current  goal.  One  approach  to 
finding  such  rules  uses  intersection  search.  Transposition  rules  arc  represented  as  special  arcs,  e.g.. 
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PREDICATE  *=RULE329==>  QUANTIFIER 

If  the  goal  is  to  embed  f  next  to  h  in  an  expression  of  the  form  (f ...  (g  ...  (h  ...))),  the  search  looks 
for  a  path  from  f  to  g  or  from  g  to  h.  This  is  because  f  can  be  moved  next  to  g  by  transposing  f  with  g 
or  g  with  h.  For  example,  the  current  goal  is  to  embed  CAUSE  next  to  CAROS- in-hand  in  the 
expression 

(CAUSE  (EXISTS  Cl  ( CARDS- IN-HAND  PO)  (IN-SUIT  Cl  SO))) 

An  intersection  search  between  CAUSE  and  EXISTS  would  find  the  path 

CAUSE  EXISTS 

is-a  Is-a 

PREDICATE  =  =  RULE329  =  0  QUANTIFIER 


This  suggests  using  RULE329  to  transpose  CAUSE  with  EXISTS: 

Find  RULE329 :  (P  (Q  E))  ->  (Q  (P  E)) 
RULE329  lhs:  (P  ...  (Q  *  S  Ex)  .,,) 

RULF.329  can  be  applied  to  the  current  expression,  but  (CARDS- IN-HAND  PO)  is  in  the  wrong 

position  to  achieve  the  desired  effect  of  moving  it  next  to  CAUSE: 

/  (EXISTS  Cl  (CARDS-IN-HAND  PO) 

/  (IN-SUIT  Cl  SO)) 

\  (Q  x  S  (CARDS-IN-HAND  PO)) 


This  suggests  iranferring  (CARDS-IN-HAND  PO)  from  S  into  Ex  in  (Q  x  S  Ex): 

Transfer  (CARDS-IN-HAND  PO) 


One  of  foo’s  transfer  rules  (§5.10.2)  (choosing  it  is  an  interesting  problem!)  is 

RULE135:  (Q  x  (set-of  y  S  P  )  R^)  ->  (Q  x  S  (and  R^))  --  move  P  into  quantified  condition 

RULE135  transfers  P  from  the  scope  of  the  quantifier  variable  x  into  the  condition  quantified  over 

x.  Here Q  =  EXISTS,  P  =  at’.R,  =  (IN-SUIT  Cl  SO), 
y  * 

Find  RULE135 

RULE135  lhs:  (Q  x  (set-of  . . . ) 

Rx) 

However,  the  current  expression  (EXISTS  Cl  (CARDS-IN-HAND  PO)  (IN-SUIT  Cl  SO)) 
mismatches  the  left  side  (Q  x  (set-of  S  Py)  Rx)  of  RULE135: 

/  CARDS-IN-HAND 
\  SET-OF 
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'Phis  difference  is  eliminated  by  RULE124,  suggested  by  the  arc 
CARDS- IN-HAND  --RUL£124-->  SET-OF 

Find  RULE124 
(CARDS- IN-HAND  PO) 

12:4  ---  [by  RULE124]  ---> 

(SET-OF  C2  (CARDS) 
(HAS  PO  C2 ) ) 


The  partial  plan  at  this  point  looks  like  this: 

Prove  (NOT  (DURING  ( ROUND- IN-PROGRESS )  (UNDO  (VOID  PO  SO)))) 

RULE236 :  NOT  CONSTANT  ->  T 

RULE57 :  DURING  KNOWN-ACTION  ->  NIL 
12:3  RULE377 :  UNDO  NQI  '>  CAUSE 

12:2  RULE  124:  VOID  ->  NOT 

RULE358 :  CAUSE  AJ  ->  MOVE 

RULE329:  embed  CAUSE  next  to  quantified  condition 
RULE135 :  Q  x  (SET-Of  y  S  P)  R  ->  transfer  P 
12:4  RULE  124 :  CAROS- IN-HAND  ->  SET-OF 

RULE  123:  MOVE  ->  KNOWN-ACTION 

RULE135  can  now  be  used  as  suggested  to  transfer  from  S  to  R  in  (Q  x  S  P).  However,  the 
expression  transferred  is  not  (CARDS- IN-HAND  PO),  but  (HAS  PO  Cl).  This  is  alright,  because  the 
reason  for  transferring  (CAROS-IN-HAND  PO)  was  tire  semantic  connection  between 
CARDS- IN-HAND  and  AT,  and  there  exists  an  even  closer  connection  between  HAS  and  AT.  The 
restructuring  goals  should  not  refer  to  the  specific  expression  (CARDS- In-hand  PO),  but  to  the 
intensionally  specified  “expression  defined  in  terms  of  AT.” 

This  is  an  opportune  point  to  note  that  the  example  would  be  much  easier  to  describe  if  step  12:8, 
where  ( HAS  PO  C 1 )  is  expanded  in  terms  of  AT,  occurred  earlier  in  the  derivation.  When  1  originally 
generated  DERIV12,  I  deferred  this  step  as  long  as  possible  in  order  to  keep  the  current  expression 
shorter.  There  are  actually  several  differences  between  the  expression  following  12:3  -- 
(CAUSE  (EXISTS  Cl  (CAROS-IN-HANO  PO)  (IN-SUIT  Cl  SO) ) )  --  and  RULE358's  left  side 
(cause  (at  obj  loc)).  (Recall  that  RULE358  is  the  second  rule  in  the  high-level  3-step  plan  for 
translating  (UNDO  (VOID  PO  SO))  into  a  known  action.)  The  argument  to  CAUSE  should  be  AT. 
Instead,  it  contains  (rather  than  is)  an  expression  indirectly  (rather  than  directly)  defined  in  terms  of 
(rather  than  equal  to)  the  desired  symbol  AT. 

DERIV12  addresses  the  structural  difference  before  the  semantic  mismatch: 
(CAROS-IN-HANO  PO)  is  moved  closer  to  CAUSE  before  expanding  it  in  terms  of  AT.  It  is  expanded 
into  (SET-OF  C2  (CARDS)  (HAS  PO  C2) )  at  step  12 :  4  only  so  that  RULE135  (and  consequently 
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RULE329)  can  be  applied.  An  automatic  problem-solver  might  find  it  easier  in  general  to  resolve 
semantic  mismatches  before  reducing  structural  differences. 


RULE135  transfers  the  expression  (HAS  PO  C 2)  into  the  desired  position: 

(EXISTS  Cl  (SET-OF  Cl  (CARDS) 
(HAS  PO  C2 ) ) 
(IN-SUIT  Cl  SO)) 

12:5  —  [transfer  by  RULE135]  — > 

(EXISTS  Cl  (CARDS) 

(AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO])) 


Now  (HAS  PO  Cl )  is  in  the  right  position  for  RULE329  to  embed  CAUSE  closer  to  it: 

(CAUSE  (EXISTS  Cl  (CARDS) 

(AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO]))) 

12:6  -  [transpose  by  RULE329]  - > 

(EXISTS  Cl  (CARDS) 

(CAUSE  (AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO]))) 


However,  HAS  is  still  not  adjacent  to  CAUSE  as  it  must  be  to  match  RULE358’s  left  side: 

/  (CAUSE  (AND  (HAS  . . .)  . . .) 
\  (CAUSE  (AT  ?OBJ  7L0C)) 


The  goal  at  this  point  is  to  embed  CAUSE  next  to  HAS  in  the  expression 
(CAUSE  (ANO  [HAS  PO  Cl]  [IN-SUIT  Cl  SO])) 

An  intersection  search  between  CAUSE  and  AND  (§7.3)  would  find  the  path 
CAUSE  Is-a  AFFECT  ==RULE35==>  AND 


This  suggests  that  CAUSE  can  be  embedded  next  to  HAS  by  the  transposition  rule 

RULE35:  (C  (and  Pj ...  Pn))  ->  (and  [C  P]  P, ...  PH  P.+  y ...  Pn). 

where  C  denotes  change  over  time,  e.g.,  cause  or  undo  --  embed  C  next  to  /*. 


Here C  =  CAUSE,  R  =  (HAS  PO  Cl): 


Embed  CAUSE  next  to  HAS 
Find  RULE35 


RULE35  is  directly  applicable  to  the  current  expression,  so  apply  it: 
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(CAUSE  (AND  [HAS  PO  Cl] 

[IN-SUIT  Cl  SO])) 

12:7  ---  [REDUCE  by  RULE35]  ---> 

(AND  [CAUSE  (HAS  P0  Cl)] 
[IN-SUIT  Cl  SO]) 


This  brings  HAS  next  to  CAUSE,  but  the  resulting  expression  (CAUSE  (has  PO  Cl) )  docs  not  yet 
match  the  left  side  of  the  second  rule  in  the  3-step  plan: 


RULE358:  (cause  (at  obj  loc))  ->  (move  obj  loc’  loc),  where  loc’  is  the  previous  location  of  obj 


/  HAS 
\  AT 


The  arc  HAS  -~RULEl24-->  at  suggests  how  to  eliminate  this  difference: 

Find  RULE124 
(HAS  PO  Cl) 

12:8  ---  [RULE  124]  ---> 

(AT  Cl  (HAND  PO)) 


RULE358  can  at  last  be  applied: 


12:9 


(CAUSE  (AT  Cl  (HAND  PO))) 
---  [by  RULE358]  ---> 
(MOVE  Cl  LOCI  (HAND  PO)) 


RULE358  was  the  second  rule  in  a  3-stcp  plan  for  reformulating  (UNDO  (VOID  PO  SO) )  in  terms 
of  a  known  action: 


(1)  (2)  (3) 

UNDO  --RULE377->  CAUSE  ~-RULE358->  MOVE  --RULE123->  KNOWN-ACTION 


When  this  plan  was  constructed,  it  wasn’t  known  which  action  MOVE  would  be  recognized  as,  but 
only  GET -card  matches  the  current  expression: 

(MOVE  Cl  LOCI  (HAND  PO)) 

12:10  [by  RULE123]  — > 

(GET-CARD  PO  Cl  LOCI) 


The  proof  plan  at  this  stage  of  partial  execution  looks  like  this: 
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Prove  (NOT  (DURING  (ROUND-IN-PROGRESS)  (UNOO  (VOID  PO  SO)))) 
RULE236:  NOT  CONSTANT  ->  T 

RULE 5 7  :  DURING  KNOWN-ACTION  ->  NIL 
12:3  (1)  RULE377 :  UNOO  NOT  ->  CAUSE 

12:2  RULE124 :  VOID  ->  NOT 

12:9  (2)  RULE358 :  CAUSE  M  '>  MOVE 

12:6  RULE329:  embed  CAUSE  next  to  quantified  condition 

12:5  RULE  135 :  Q  x  fSET-OF  y  S  P)  R  ->  transfer  P 

12:7  RULE35:  embed  CAUSE  next  to  HAS 

12:8  RULE124:  HAS  ->  AT 

12:4  RULE124:  CARDS- IN-HANO  ->  SET-OF 

12:10  (3)  RULE123:  MOVE  ->  KNOWN-ACTION 


The  3-stcp  plan  for  reformulating  (UNDO  (VOID  PO  SO))  in  terms  of  a  known  action  has  now 

been  successfully  executed,  enabling  the  application  of  RULE57: 

(DURING  ( ROUND- IN- PROGRESS) 

(EXISTS  Cl  (CAROS) 

(AND  [GET-CARD  PO  Cl  LOCI] 

[IN-SUIT  Cl  SO]))) 

12:11  ---  [COMPUTE  by  RULE57]  ---> 

NIL 


This  transforms  AlOT’s  argument  into  the  constant  NIL,  allowing  RULE236  to  be  applied: 

(NOT  NIL) 

12:12  —  [COMPUTE  by  RULE236]  — > 

T 


The  initial  expression  has  now  been  transformed  to  T,  Le.,  proved. 


7.4.  Means-End  Analysis  for  Operationalization:  Summary 

Means-end  analysis  appears  to  be  a  promising  technique  for  automating  at  least  some  of  the  kind 
of  problem-solving  exhibited  in  the  derivations.  It  requires  a  suitable  representation  for  problem 
states,  goal  states,  and  differences  between  them,  and  mechanisms  for  finding  the  right  operator 
(transformation  rule)  to  reduce  a  specified  difference. 

Problem  states  are  simply  expressions;  goal  states  can  be  abstract  descriptions  of  expressions,  e.g., 
the  variabilizcd  patterns  on  the  left-hand  sides  of  rules.  The  search  should  be  more  focussed  if  the 
initial  goal  is  relatively  concrete  rather  than  simply  “operationalize  e."  Concrete  goals  include: 

“Prove  P”  --  transform  P  into  T 

“Apply  method  M  to  expression  e"  -  transform  e  to  match  the  problem  statement  for  M 


There  are  two  basic  kinds  of  expression  differences,  semantic  and  structural.  Semantic  differences 
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involve  mismatches  between  components  of  expressions.  Structural  differences  involve  components 
being  in  the  wrong  positions,  e.g.,  transposed.  Relations  useful  in  describing  differences  include: 

1.  f  is-a  g:  either  f  =  g  or  there  is  a  path  from  f  to  g  consisting  of  is-a  links. 

2.  e  has  g  as  its  head:  e  =  (g ...) 

3.  e  contains  g:  e  =  (...  g ...),  Le.,  g  occurs  as  a  (possibly  nested)  sub-expression  of  e 

4.  f  is  adjacent  to  g  in  e:  c  contains  (f  ej ...  (g  ...) ...  en),  Le.,  f  has  (g  ...)  as  an  argument 

5.  f  is  directly  defined  in  terms  of  g:  f  is  defined  as  (lambda  (...)  (g ...)) 

6.  f  is  defined  in  terms  of  g:  transitive  closure  of  “directly  defined  in  terms  of’ 

7.  f  directly  mentions  g  in  its  definition:  f  is  defined  as  (lambda  (...)  (...  g  ...)) 

8.  f  mentions  g  in  its  definition:  transitive  closure  of  "directly  mentions  in  its  definition” 

These  properties  arc  partial-ordered  insofar  as  some  imply  others: 

f  =  8 

=  >  fis-a  g 

e  has  g  as  its  head 
=  >  e  contains  g 

f  is  adjacent  to  g  in  e 
=  >  e  contains  f,g 

f  =  g  or  f  is  directly  defined  in  terms  of  g 
=  >  f  is  defined  in  terms  of  g 
=  >  f  directly  mentions  g  in  its  definition 
=  >  f  mentions  g  in  its  definition 

Differences  can  be  understood  in  terms  of  expressions  that  fail  to  satisfy  desired  relations.  For 
example,  the  pattern  (cause  (at  ?obj  ?loc))  on  the  left  side  of  RULE358  can  be  described  as  a 
conjunction  of  relations  between  an  expression  c  and  two  symbols  fand  g: 

1.  e  has  f  as  its  head 

2.  f  =  CAUSE 

3.  f  is  adjacent  to  g  in  e 

4.  g  =  AT 

The  expression  e  =  (CAUSE  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO)))  is 
characterized  by  a  conjunction  of  weaker  relations: 


T.  e  has  f  as  its  head 
2’.  f  =  CAUSE 
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3’.  e contains g  =  CARDS-IN-HAND 
4’.  g  mentions  AT  in  its  definition 

The  pattern  and  expression  both  satisfy  properties  1  and  2.  The  expression  violates  3  but  satisfies 
3’.  This  indicates  a  structural  difference,  since  its  elimination  involves  moving  g  next  to  f.  Similarly, 
the  expression  violates  4  but  satisfies  4’.  This  indicates  a  semantic  difference,  since  eliminating  it 
involves  expanding  the  definition  of  g.  In  other  words,  the  classification  of  a  difference  as 
"structural"  or  "semantic"  depends  not  only  on  what  relation  is  violated  but  on  what  weaker  relation 
may  be  satisfied  in  its  place.  Perhaps  a  better  way  to  put  this  is  to  say  that  the  choice  of  an  operator  to 
move  an  expression  towards  a  desired  pattern  should  depend  not  only  on  the  differences  between 
expression  and  pattern  but  on  their  similarities,  le..  die  relations  they  satisfy. 


The  point  of  the  structural/scmantic  distinction  is  to  classify  differences  according  to  die  kinds  of 
operators  required  to  reduce  them.  Typically,  structural  differences  are  reduced  by 
restructuring  (^5.10)  and  semantic  differences  by  translation  (§5.8). 


The  choice  of  a  rule  to  reduce  a  difference  between  an  expression  and  a  pattern  should  be 
constrained  by  exploiting  information  about  the  expression,  the  pattern,  and  die  nature  of  the 
difference.  Intersection  search  (§5.6)  provides  a  way  to  integrate  these  diree  sources  of  constraint. 
Intersection  search  looks  for  a  path  between  two  nodes  in  a  graph.  For  a  semantic  difference,  a 
symbol  in  the  expression  is  one  starting  node,  and  the  corresponding  symbol  in  die  pattern  is  the 
other.  For  a  structural  difference,  the  two  starting  nodes  are,  for  example,  two  functions  to  be 
transposed  in  the  expression.  The  kinds  of  arcs  allowed  in  the  path  arc  determined  by  the  nature  of 
the  difference: 

1.  Both:  Is-a  links.  This  makes  it  possible  to  find  paths  from  specific  functions  in  die  current 
expression  to  general  concepts  used  in  rule  patterns  and  goals. 

2.  Semantic:  An  arc  between  the  head  symbols  of  each  translation  rule's  left  and  right  sides.  If 
diese  are  the  same,  multiple  arcs  arc  used  between  corresponding  lower-level  symbols  of  each 
side.  RULE124  (elaboration)  and  RUI.E123  (recognition)  are  specially  represented  by  an  arc 
between  each  function  and  the  head  function  in  its  definition. 

3.  Structural:  Arcs  for  each  restructuring  rule.  For  example,  a  transposition  rule  is  represented 
by  an  arc  between  the  transposed  symbols.  It  is  unclear  how  to  encode  certain  restructuring 
rules  as  arcs  (associations  between  two  symbols)  in  a  way  that  preserves  enough  information  to 
effectively  constrain  the  search.  For  example,  an  arc  between  Quantifier-scope  and 
QUANT! F IED-CONDIT ION  would  encode  only  partial  information  about  the  effect  of  the 
transfer  rule 
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RULE135:  (Q  x  (set-of  y  S  P  )  Rx)  ->  (Q  x  S  (and  Px  Rx))  --  transfer  P  to  quantified 
condition 

The  purpose  of  such  intersection  search  is  to  generate  a  plausible  plan  (operator  sequence)  to  solve 
a  given  operationalization  problem  or  sub-problem.  Each  step  in  such  a  plan  consists  of  applying  a 
transformation  rule.  If  the  current  expression  matches  the  left  side  of  the  next  rule  in  die  plan,  the 
rule  is  applied  immediately;  otherwise  a  subproblem  is  generated  to  reduce  the  differences  between 
them.  Thus  the  means-end  analysis  operates  in  a  problem-reduction  mode,  executing  plan  steps 
when  possible  and  expanding  the  plan  when  necessary  to  enable  execution  of  the  next  step,  'Phis  sort 
of  problem-solving  can  be  viewed  as  planning  in  a  hierarchy  of  abstraction  spaces  [Sacerdoti  77J;  the 
n^-level  abstraction  of  an  expression  is  constructed  by  ignoring  sub-expressions  nested  below  depth 
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Chapter  8 
Further  Research 

The  research  described  in  this  dissertation  can  be  extended  in  several  directions,  some  specifically 
related  to  operationalization,  others  broader  in  scope.  (§8.1)  discusses  aspects  of  operationalization 
that  need  further  attention.  (§8.2)  discusses  related  aspects  of  machine-aided  heuristic 
programming  [Haycs-Roth  78a],  a  knowledge  engineering  approach  based  on  mechanical 
operationalization  of  advice  supplied  by  an  expert  or  inferred  from  experience.  (§8.3)  discusses  some 
general  Al  issues  connected  with  this  work.  Areas  for  further  research  arc  summarized  in  (§9.2). 


8.1.  Further  Research  in  Operationalization 

As  an  operationalization  engine,  roo  is  very  incomplete;  it  was  designed  as  an  exploratory  research 
vehicle  rather  than  for  production  use.  The  hand-simulated  control  made  it  possible  to  do  without 
several  features  that  would  be  required  otherwise,  such  as  mechanisms  for  choosing  which  rule  to 
apply  next,  keeping  track  of  alternative  paths,  and  deciding  when  to  stop  (§8.1.1).  A  practical 
operationalizer  would  need  to  be  more  time-  and  space-efficient  than  1-00  (§S.1.2).  Extending  TOO  to 
handle  a  wider  range  of  advice  would  require  expanding  its  repertoire  of  operationalization 
strategics  (§8.1.3)  and  analysis  methods  (§8.1.4).  A  broader  approach  to  operationalization  would 
exploit  information  not  used  in  FOO,  such  as  knowledge  about  data  structures  (§8.1.5),  details  of  a 
specific  task  situation  (§8.1.6).  and  experience  both  in  performing  the  task  and  in  operationalizing 
previous  advice  (§8.1.7). 

8.1.1.  Control 

To  simplify  the  operationalization  problem  I  hand-simulated  control  decisions  about  which  rule  to 
apply  at  each  point  in  the  derivations.  A  complete  operationalizer  would  have  to  make  such  decisions 
automatically.  Pure  trial-and-error  is  inadequate  here  because  of  the  combinatorics  of  the  search 
space.  The  depth  of  this  space,  i.e.,  the  length  of  the  chains  of  reasoning  required  to  operationalize 
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advice,  is  indicated  by  the  length  of  the  derivations,  some  of  them  over  100  steps  long.  The 
branching  factor  of  the  search  space  is  also  large,  both  because  many  rules  are  syntactically  applicable 
at  each  point  in  a  derivation,  and  because  a  transformation  can  be  applied  to  any  sub-cxpiession  of 
the  current  expression. 

Static  rule  ordering  proved  inadequate  as  a  means  of  rule  selection.  For  example,  in  situations 
where  an  expression  can  be  either  elaborated  in  terms  of  a  lower-level  concept  (§5.8.2)  or  recognized 
in  terms  of  a  higher-level  concept  (§5.8.3),  sometimes  one  transformation  is  appropriate  and 
sometimes  the  other  is.  In  short,  avoiding  a  combinatorial^  explosive  search  requires  rule  selection 
to  be  made  very  carefully,  i.e.,  based  on  as  much  knowledge  as  possible. 

Means-end  analysis  appears  to  offer  a  promising  approach  for  guiding  the  operationalization 
process  (§7.3).  The  requirements  of  this  approach  are  described  below. 

First  it  must  be  possible  to  represent  operationalization  goals  such  as: 

Find  a  way  to  evaluate  expression  e. 

Construct  a  plan  to  achieve  task  goal  G. 

Figure  out  how  to  apply  method  M  to  problem  P. 

Reformulate  expression  c  so  as  to  match  pattern  p. 

A  mechanism  is  needed  for  finding  a  suitable  operationalization  strategy  to  achieve  a  given 
operationalization  goal.  (§2.13)  characterizes  FOO's  operationalization  strategies  in  terms  of  their 
usefulness  in  eliminating  various  obstacles  to  runtime  operationality.  Fror  example,  the  pigeon-hole 
principle  (§2.2)  is  useful  in  evaluating  certain  expressions  formulated  in  terms  of  unobservable  data, 
such  as  the  condition  “the  Queen  of  spades  is  out."  Finding  an  operationalization  strategy  for  an 
expression  based  on  analysis  of  why  it  is  non-operational  is  a  key  research  problem  to  be  solved  in 
designing  an  automatic  operationalizer. 

It  must  be  possible  to  identify  differences  between  the  current  state  and  an  operationalization  goal, 
such  as: 

Expression  e  contains  a  sub-expression  that  will  not  be  evaluable  at  runtime. 

Action  A  will  not  be  directly  executable  at  runtime. 

Problem  P  is  not  expressed  in  the  same  language  as  method  M. 

Two  occurrences  of  variable  x  in  rule  R  correspond  to  unequal  components  of  expression  e. 
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Applying  an  operationalization  strategy  to  an  expression  requires  die  ability  to  find  a  suitable 
operator  to  reduce  a  difference.  This  requires  knowledge  about  the  kinds  of  differences  each  method 
reduces.  A  semantic  difference,  such  as  a  mismatch  between  a  component  of  the  expression  and  the 
corresponding  element  of  the  left-hand  side  of  the  rule,  may  be  reduced  by  reformulating  the 
component  in  terms  of  the  concept  used  in  the  rule  (§7.1.1).  A  structural  difference,  for  example 
between  the  order  of  two  pattern  elements  in  a  rule  and  the  order  of  the  corresponding  components 
in  the  expression,  may  be  reduced  by  restructuring  the  expression  in  a  suitable  manner  (§7.1.3). 

(§7)  illustrates  how  intersection  search  could  be  used  to  find  a  suitable  rule  for  reducing  a  given 
semantic  or  structural  difference  between  a  current  expression  and  a  goal  pattern.  This  approach 
exploits  information  about  the  similarity  or  semantic  relationship  between  the  expression  and  the 
goal  as  well  as  their  differences;  for  example,  finding  that  the  expression  is  indirectly  defined  in  terms 
of  the  goal  concept  would  suggest  elaborating  the  expression  by  plugging  in  its  definition. 

If  an  operator  with  parameters  is  selected,  it  may  be  necessary  to  decide  how  to  instantiate  the 
operator.  Some  of  r-'OO’s  rules  require  selecting  from  a  set  of  clauses  in  a  problem  or  a  set  of  concepts 
retrieved  from  the  knowledge  base  (§6.5).  Certain  types  of  domain  knowledge  could  help  constrain 
such  choices.  For  example,  a  rule  for  undoing  a  conjunction  selects  one  of  the  conjuncts  to 
undo  (§2.5.1).  This  Rile  could  be  constrained  not  to  select  a  conjunct  known  to  be 
immutable  (§6.6.1. 1). 

The  search  control  mechanism  must  be  able  to  decide  if  it  is  semantically  appropriate  (e.g.,  logically 
valid  or  sound)  to  apply  a  given  operator  to  a  given  expression  for  a  given  purpose.  I  formulated 
mechanical  tests  of  soundness  or  validity  for  many  of  FOO’s  rules,  but  was  unable  to  do  so  for  several 
others  (§6.6).  In  r  oo,  the  logical  status  of  the  current  expression  is  often  implicit.  An  automatic 
operationalizer  would  need  to  know  the  logical  relationship  between  the  current  expression  and  the 
operationalization  goals  that  produced  it. 

For  example,  if  the  goai  is  to  achieve  some  condition  C,  it  is  legitimate  to  transform  C  into  a 
stronger  condition  C’,  since  C  will  be  achieved  if  C  is.  However,  if  die  goal  is  to  evaluate  C, 
transforming  it  into  C’  leads  at  best  to  a  partial  solution  in  the  sense  that  when  C  is  known  to  be  true, 
so  will  C,  but  the  falsehood  of  C’  implies  nothing  about  the  truth  value  of  C.  Making  logical  status 
explicit  would  also  require  replacing  the  implicitly  quantified  variables  used  for  brevity  in  some  rules 
and  concept  definitions  with  explicidy  quantified  variables,  or  adding  a  scheme  to  mark  variables  as 
existential,  universal,  or  global. 


348 


§8.  Further  Research 


t 


The  ability  to  pursue  alternative  operationalization  paths  requires  appropriate  bookkeeping.  FOO 
didn't  need  a  backtracking  mechanism,  since  I  only  led  it  down  correct  paths.  The  ability  to  search 
for  an  operational  solution  by  trying  multiple  paths  would  require  the  ability  either  to  undo  the 
effects  of  global  assumptions  and  variable  assignments,  or  to  confine  these  effects  to  separate  contexts 
by  means  of  mechanisms  similar  to  those  used  in  truth  maintenance  systems  [Doyle  81]  and 
partitioned  semantic  networks  [Hendrix  75], 

The  operationalizer  must  know  when  to  stop.  Deciding  whedier  an  expression  is  operational 
requires  knowledge  about  runtime  capabilities.  Encoding  such  knowledge  requires  the  ability  to 
refer  to  different  times.  For  example,  the  trick-winner  is  known  at  the  end  of  the  trick  but  not  in  the 
middle.  Inferring  such  knowledge  from  the  task  description,  ie.,  predicting  whether  an  expression 
will  prove  operational  in  the  situations  in  which  it  will  be  used,  requires  a  model  of  time,  choice, 
observation,  and  memory.  For  example,  an  opponent’s  choice  of  what  card  to  play  becomes  known 
when  the  card  is  played.  Thus  once  a  trick  begins,  the  suit  led  will  be  known,  but  not  (in  general) 
whether  the  trick,  will  have  points,  since  this  depends  on  cards  not  yet  played. 

FOO’s  evaluation  of  operationality  is  limited  to  a  procedure  that  takes  an  expression  and  returns  a 
list  of  functions  which,  if  executable,  guarantee  that  the  expression  is  operational,  as  shown  in 
Appendix  F..  The  problem  of  testing  operationality  is  further  complicated  by  the  fact  that 
operationality  is  relative:  the  more  often  a  procedure  can  be  executed,  and  the  more  accurate  its 
results,  the  more  operational  it  is.  In  practice  operationality  might  have  to  be  evaluated  empirically, 
by  applying  the  procedure  to  actual  task  situations  and  seeing  how  often  it  produces  the  desired 
results. 

8.1.2.  Efficiency 

FOO's  design  emphasizes  generality  at  the  cost  of  efficiency.  A  useful  system  would  need  to  be 
more  efficient  in  time  and  space. 

FOO  takes  over  300K  on  a  PDP-10,  partly  because  it  holds  the  entire  derivation  in  core.  An 
obvious  remedy  is  to  store  only  the  information  required  to  continue  the  search  or  backtrack  to  an 
earlier  point:  the  current  stack  of  operationalization  goals,  plus  information  about  the  approaches 
that  have  been  tried  on  each  one.  However,  a  practical  operationalizer  might  well  need  large 
amounts  of  memory,  for  example  more  than  the  address  space  of  a  PDP-10.  This  suggests  using  a 
machine  with  virtual  memory  and  a  large  address  space  -*  at  least  until  multi-million-word  primary 
memories  become  sufficiently  cheap  to  support  the  escalating  demands  of  AI  research. 
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It  proved  necessary  to  disable  a  feature  of  foo  that  listed  all  the  mles  applicable  to  the  current 
expression,  because  it  took  too  long  to  test  the  rule  conditions  (Le.,  longer  than  1  was  willing  to  sit  and 
wait).  Automatic  rule  selection,  or  even  interactive  rule  selection  (where  the  system  recommends  a 
rule  and  the  user  accepts  it  or  asks  for  another),  would  require  a  more  patient  user  or  a  more  efficient 
implementation.  Means-end  analysis  (§7)  would  help  here  by  considering  only  rules  relevant  to 
current  operationalization  goals,  rather  than  identifying  all  syntactically  applicable  rules. 

Compiling  frequently-used  rule  sequences  into  procedures  would  extend  the  range  of  possible 
solutions  that  could  be  explored  given  specified  time  and  space  resour.es.  In  particular, 
simplification  rules  could  be  incorporated  into  a  quasi-canonicalization  procedure  applied  after  each 
transformation  (§5.2.5).  Special-purpose  inheritance  mechanisms  could  be  added  to  make  certain 
kinds  of  deductions  requiring  sequences  of  rule  applications  in  FOO,  such  as  verifying  that  an 
intcnsionally  described  object  (or  set)  is  a  member  (or  subset)  of  a  particular  class.  Such  mechanisms 
would  require  explicit  representation  of  type  information  encoded  in  FOO  as  domain-specific  “fact 
rules”  (§1.3.3). 

Specialized  methods  could  exploit  a  frozen  (as  opposed  to  open-ended)  set  of  concepts  or 
canonical  representation.  For  example,  FOO’s  intersection  search  procedures  (§5.6)  circumvent  the 
detailed  case  analysis  that  might  otherwise  be  required  to  reject  certain  impossible  propositions. 
Their  validity  is  based  on  some  completeness  assumptions  about  the  knowledge  base  (§6.5.1). 

8.1.3.  Representation  of  Operationalization  Methods 

FOO  has  only  a  few  operationalization  methods.  A  useful  operationalizer  would  require  many 
more  and  might  profitably  exploit  existing  general  techniques  for  planning  [Sacerdoti  77]  [Carbonell 
78]  and  automatic  programming  [Manna  79]  [Barstow  77], 

8. 1.3.1  Acquisition  of  Operationalization  Methods 

Developing  a  large  repertoire  of  general  operationalization  methods  would  be  easier  if  they  could 
be  acquired  in  the  same  manner  as  task-specific  concepts  and  heuristics.  Ideally,  it  should  be  possible 
to  improve  an  operationalizer  simply  by  telling  it  about  a  new  concept,  such  as  the  distribution  of 
cards  in  a  suit  (§6.5.5);  the  concept  could  then  be  used  to  operationalize  advice.  Assimilating  new 
operationalization  strategies  expressed  in  the  same  representation  as  domain  knowledge  is  an 
interesting  and  difficult  problem. 
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A  useful  step  towards  this  ideal  is  the  development  of  a  declarative  conceptual  representation  for 
the  kinds  of  knowledge  involved  in  understanding  a  method:  its  scope  of  application,  its 
informational  requirements,  and  the  factors  determining  the  accuracy  of  its  result.  Such  a 
representation  would  make  an  easier  target  for  mechanical  interpretation  of  informal  input  than  the 
transformation  rule  format  in  which  FOO’s  methods  are  hand-coded.  Since  an  operationalization 
strategy  is  a  way  to  implement  a  desired  capability  in  terms  of  the  operations  available  to  a  given  task 
agent,  a  representation  of  such  a  strategy  may  need  to  refer  to  a  model  of  the  task  agent.  The  simple 
task  agent  model  presented  in  (§1.1.1)  is  useful  in  explaining  some  operationalization  strategies,  but 
would  have  to  be  extended  to  deal  with  strategies  for  reducing  computational  costs,  such  as  methods 
for  speeding  up  a  heuristic  search  (§3.4). 

8.1.3.2  Representation  of  AI  Methods 

foo's  representation  of  the  heuristic  search  method  was  inspired  by  Newell’s  flow  graph  schemata 
for  the  weak  methods  [Newell  69].  Moore  encoded  the  flow  graph  for  heuristic  search  as  a  semantic 
network  in  MF.RLIN,  and  instantiated  it  by  hand  to  form  an  operational  version  of  the  Logic 
Theorist  [Moore  74],  This  dissertation  extends  Moore’s  work  by  showing  how  such  an  instantiation 
process  might  be  mechanized  (§3).  Encoding  other  AI  methods  in  a  form  conducive  to  mechanical 
application  is  a  challenging  and  worthwhile  research  problem. 

8.1.4.  Analysis  Methods 

Analysis  makes  contact  between  general  operationalization  ideas  and  specific  problems.  Analysis 
subsumes  theorem-proving  in  the  sense  that  the  latter  can  be  defined  as  symbolically  transforming  a 
proposition  into  a  truth  constant,  while  the  former  reduces  an  expression  (not  necessarily  boolean) 
into  one  that’s  simpler  or  easier  to  operationalize  (not  necessarily  constant).  Moreover,  thcorem- 
provers  are  restricted  to  logically  correct  transformations,  while  analysis  may  use  hcuristically  useful 
transformations  whose  results  are  occasionally  incorrect  but  usually  lead  to  good  performance. 
Researchers  in  program  verification  have  observed  that  verification  conditions  rarely  reduce  to  true 
or  false,  and  that  mechanical  reduction  of  a  program's  correctness  precondition  can  help  pinpoint 
errors  in  the  program  or  its  specifications  [Nelson  79]. 

FOO’s  analysis  rules  were  formulated  to  handle  the  particular  operationalization  problems 
undertaken,  sometimes  in  a  somewhat  ad  hoc  fashion.  Their  purpose  is  to  indicate  (not  necessarily 
provide)  analysis  capabilities  useful  in  operationalization.  A  practical  general-purpose  operationalizer 
would  need  a  more  powerful  analysis  engine.  Several  steps  would  help  toward  this  goal: 
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1.  Formulate  soundness  and  validity  tests  missing  in  some  of  FOO’s  rules  (§6.6). 

2.  Generalize  FOO’s  rules  to  apply  the  same  transformations  to  a  wider  range  of  expressions. 

3.  Develop  new  rules  for  additional  analytic  transformations. 

4.  Develop  analysis  methods  that  exploit  semantic  relations  among  task  concepts  (§6.1). 

5.  Incorporate  systematic  proof  procedures  based  on  special-purpose  representations  (§2.10.3) 
(§5.6)  (§6.1). 

8.1.5.  Knowledge  About  Memory 

Several  researchers  have  worked  on  the  problem  of  mechanically  designing  or  selecting  an 
appropriate  data  structure  for  a  given  problem  (Rovner  76}  [Low  78}[Barstow  77],  FOO  addresses 
only  the  first  step  of  this  process,  namely  identifying  what  information  is  necessary  or  sufficient  to 
calculate  a  given  quantity  (§2.4).  Some  of  the  “operational''  procedures  derived  using  FOO  contain 
historical  references  to  such  quantities  as  the  number  of  times  a  particular  kind  of  event  has  taken 
place  during  a  specified  time  period  (§2.4.3).  Implementing  such  a  solution  requires  a  mechanism  for 
monitoring  and  counting  such  events.  FOO  has  a  search  refinement  rule  for  recognizing  that  a 
particular  function  can  be  precomputed  and  stored  in  a  table  before  the  search  (§3.5.3.2),  but  FOO’s 
applicative  representation  provides  no  way  to  refer  to  such  tables.  A  more  complete  treatment  of 
time-based  concepts  would  require  an  explicit  representation  of  memory  processes  and  data  structures. 

8.1.6.  Dynamic  Operationalization 

Dynamic  operationalization  reduces  a  general  operationalization  problem  to  an  easier  one  by 
exploiting  an  additional  source  of  knowledge  -  the  features  of  a  specific  task  situation.  For  example, 
if  the  King  of  diamonds  has  been  led,  the  advice  “avoid  taking  points”  can  be  operationalized  as 
“underplay  the  King  of  diamonds”  (§5.4.4).  Dynamic  operationalization  is  to  situation-independent 
operationalization  as  planning  is  to  automatic  programming  (§9.1.1):  it  solves  an  easier  problem  but 
produces  a  less  general  result 

A  practical  operationalizer  might  try  to  do  as  much  reasoning  as  possible  in  a  situation- 
independent  manner,  and  then  use  dynamic  operationalization  to  find  special-case  solutions  for 
remaining  problems.  For  example,  the  advice  “avoid  taking  points”  can  be  partly  operationalized, 
without  reference  to  a  specific  trick,  as  “underplay  one  of  the  other  cards  in  the  trick."  It  is  not 
possible  in  general  to  predict  “the  other  cards  in  the  trick."  However,  it  is  often  possible  to 
dynamically  operationalize  “underplay  another  card  in  the  trick"  in  the  context  of  a  particular  trick. 
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for  example  by  underplaying  a  card  that  has  already  been  played  or  that  one  knows  will  have  to  be 
played.  In  situations  lacking  such  a  spccial-case  solution,  it  may  be  possible  to  revert  to  a  general  but 
less  effective  solution,  e.g.,  “play  a  low  card.”  Automatically  discovering  such  combinations  of  general 
and  dynamic  operationalization  is  a  problem  for  future  research. 

8.1.7.  Applications  of  Learning 

Sources  of  data  from  which  an  operationalizer  could  learn  include: 

Dl.  Description  of  the  task  domain. 

D2.  Advice  for  performing  the  task. 

D3.  Observations  made  in  actual  or  hypothetical  task  situations. 

D4.  Operationalized  advice. 

D5.  Derivations  of  operational  solutions. 

D6.  Attempts  to  operationalize  advice,  both  successful  and  unsuccessful. 

Methods  that  could  be  used  to  learn  from  this  data  include: 

LI.  Analysis',  logical  or  heuristic  deduction  of  new  knowledge  from  old. 

L2.  Learning  from  examples :  generalizing  from  individual  events. 

L3.  Learning  from  experience:  gradual  accrual  of  knowledge  from  a  scries  of  events. 

Applications  of  learning  in  operationalization  can  be  characterized  according  to  which  methods  are 
applied  to  what  data: 

[Dl,  D2,  LI]  FOO  lies  squarely  at  the  analytic  end  of  the  analytic-to-empirical  spectrum  of 
inference  methods.  This  rather  narrow  approach  to  operationalization  could  be  extended  by 
exploiting  empirical  paradigms  for  knowledge  acquisition,  as  illustrated  by  the  succeeding  proposals 
for  further  research. 

[Dl,  LI]  plus  [D3,  1.3]  The  marriage  of  analytic  and  empirical  techniques  appears  promising.  For 
example,  if  analytic  techniques  predict  that  one  quantity  is  an  increasing  function  of  another, 
empirical  data  gathered  from  task  experience  can  be  used  to  estimate  the  actual  function  (§2.8.4).  In 
general,  learning  important  relationships  among  task  components  would  improve  the  ability  to 
operationalize.  For  example,  it  is  useful  to  know  that  PLAYER-OF  is  the  inverse  of  CARO-OF  and  that 
a  player  who  is  void  in  a  suit  stays  void  for  the  rest  of  the  round  (§6.6. 1.1).  Such  facts  could  be 
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induced  by  analysis  of  the  task  description,  by  induction  from  task  experience,  or  by  some 
combination  of  the  two.  A  smart  learner  would  look  for  semantic  relationships  exploited  by  analysis 
methods,  such  as  immutability,  inverses,  and  homomorphisms.  Techniques  for  automated  discovery 
of  such  relationships  have  been  used  to  find  connections  between  mathematical  concepts  [Lcnat  78). 

[D3,  L2]  Teaching  by  example  is  a  valuable  mode  of  tutorial  instruction  not  exploited  in  FOO.  It  is 
often  easier  to  communicate  a  concept  by  an  illustrative  example  than  by  trying  to  state  it  abstractly. 
Accepting  advice  in  this  form  would  require  the  ability  to  identify  the  criterial  features  of  the 
elements  in  the  example  and  infer  the  relevant  abstraction.  The  idea  of  exemplary  programming  is 
discussed  in  [Waterman  78]. 

[D3,  D4,  L3]  Analytic  methods  are  often  inadequate  to  predict  the  operationality  of  a  heuristically 
derived  implementation  of  a  piece  of  advice  (§8.1.1).  For  example,  how  often  will  the  plan  “play  a 
low  card”  satisfy  the  goal  "avoid  taking  points?”  A  much  easier  way  to  answer  such  questions  is  to  use 
standard  reinforcement  techniques:  increase  the  estimated  worth  of  a  plan  each  time  it  works,  and 
decrease  it  when  it  fails.  This  is  similar  to  keeping  track  of  the  plan's  average  effectiveness  over  time, 
except  that  decreasing  a  plan’s  worth  will  cause  it  to  be  used  less  frequently  thereafter  when  an 
alternative  plan  is  available.  (If  there  isn’t,  such  a  decrease  will  enhance  the  priority  of  developing 
one.) 

[D2,  L3]  The  same  approach  could  be  used  to  evaluate  the  effectiveness  of  a  piece  of  advice  in 
achieving  higher-level  task  goals,  e.g.,  how  often  docs  following  the  advice  “avoid  taking  points” 
actually  lead  to  winning  the  game? 

[D4,  D5,  L2]  A  solution  generated  for  a  given  problem  can  sometimes  be  generalized  to  cover 
other  problems  as  well.  For  example,  the  plan  derived  for  deciding  whether  the  Queen  of  spades  is 
out  (§2.2.1)  can  be  generalized  to  work  for  any  card.  This  can  be  determined  by  verifying  that  none 
of  the  steps  in  the  derivation  depends  on  any  properties  specific  to  the  Queen  of  spades  other  than 
the  fact  that  it’s  a  card.  Generalizing  the  original  plan  would  consist  of  substituting  a  variable  Cl  for 
the  constant  OS  and  making  (IN  Cl  (CARDS) )  a  precondition  of  the  plan.  In  general. 

To  generalize  a  plan  P  containing  a  constant  c. 

Replace  c  with  a  variable  x  and 

Add  as  a  precondition  that  x  must  satisfy  all  tests  applied  to  c  in  the  course  of  deriving  P. 

Note  that  this  technique  relies  on  inspection  of  the  derivation  without  additional  analysis.  The  idea 
of  generalizing  a  plan  by  suppressing  irrelevant  details  was  used  in  S  TRIPS  [Saccrdoti  74],  The 
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computational  resources  required  to  generalize  a  derived  solution  are  well-spent  if  doing  so 
eliminates  the  need  to  solve  similar  problems  in  the  future. 

[D4,  L2]  A  challenging  problem  is  to  predict  the  relative  usefulness  of  different  operationalization 
methods  for  a  particular  piece  of  advice.  A  simple  approach  is  to  compile  a  record  of  each  method’s 
average  performance  along  an  appropriate  set  of  dimensions:  how  expensive  is  it  to  apply?  how 
often  docs  the  result  work?  how  expensive  is  the  result  to  use?  For  example,  a  key  measure  of  a 
heuristic  search  refinement  rule  (§3.4)  is  how  much  it  speeds  up  the  search  --  or  slows  it  down. 

[D4,  L2]  A  more  sophisticated  approach  to  evaluating  operationalization  methods  would  compare 
solutions  derived  using  alternative  methods  and  try  to  discover  individual  factors  predicting  the 
differences  between  their  performance.  For  example,  die  cost-effectiveness  of  a  rule  for  compiling  a 
constraint  out  of  a  search  by  precomputing  a  function  and  storing  it  in  a  table  (§3.53.2)  might  be 
found  to  depend  on  such  factors  as  the  depth  and  branching  factor  of  the  search  space,  die  frequency 
and  cost  of  computing  the  function,  and  the  storage  cost  for  the  table.  A  formula  based  on  these 
factors  could  be  used  in  deciding  whether  to  apply  the  rule  to  subsequent  problems.  Synthesis  of  the 
formula  and  evaluation  of  the  factors  could  draw  on  both  empirical  and  analytic  methods.  Related 
research  on  machine  comparison  of  alternative  algorithm  refinements  includes  work  on  concrete 
computational  complexity  [Kant  79[  [Wcgbreit  75]. 

[D6,  L3]  An  interesting  possibility  for  learning  about  operationalization  itself  is  to  treat  the 
operationalizer’s  own  deliberations  as  data.  One  scheme  along  these  lines  would  learn  to  apply  a 
method  only  to  problems  where  it  is  likely  to  work.  Suppose  successful  attempts  to  apply  a  particular 
method  arc  empirically  observed  as  tending  to  follow  a  common  scenario,  whereas  unsuccessful 
attempts  fail  to  get  past  some  point  in  this  scenario.  Analysis  of  both  the  successful  [Mitchell  81]  and 
unsuccessful  [Haycs-Roth  81b]  attempts  could  idenufy  tests  that  predict  when  the  method  will 
work  (§2.6.4.1).  Ihcse  tests  could  then  be  incorporated  as  conditions  for  applying  the  method. 


8.2.  Further  Research  in  Machine-Aided  Heuristic  Programming 

Mechanizing  the  operationalization  process  is  a  subprobiem  of  building  a  machine- aided  heuristic 
programming  system  capable  of  translating  informal  task  descriptions  and  advice  into  effective 
behavior.  This  section  briefly  discusses  other  problems  involved  in  implementing  the  main  phases  of 
machine-aided  heuristic  programming: 

1.  Interpret  informally  expressed  advice  and  domain  knowledge  into  an  unambiguous 
representation  (§8.2.1). 
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2.  Operationalize  advice  as  effective  plans  and  procedures. 

3.  Integrate  multiple,  possibly  inconsistent  pieces  of  advice  (§8.2.2). 

4.  Apply  advice  to  runtime  task  situations  (§8.2.4). 

[Hayes-Roth  78a)  describes  several  of  these  problems  in  greater  detail,  summarizes  some 
approaches  explored  by  other  researchers,  and  proposes  some  additional  approaches. 

It  is  important  to  note  that  the  interpretation,  operationalization,  integration,  and  application 
phases  in  a  machine-aided  heuristic  programming  system  would  overlap  in  time,  rather  than  follow  a 
strict  pipeline  flow  of  control.  For  example,  ambiguities  in  advice  might  be  resolved  in  the  context  of 
applying  it  to  a  particular  task  situation;  a  similar  approach  proved  successful  in  SAFE,  where  vague 
references  were  resolved  in  the  context  of  the  variables  active  at  runtime,  and  incorrect 
interpretations  were  discarded  when  they  led  to  runtime  errors  during  symbolic  execution  [Balzer  77). 
These  phases  have  been  separated  for  purposes  of  discussion,  and  operationalization  has  been 
considered  in  isolation  from  the  others  in  order  to  simplify  the  problems  addressed  in  the 
dissertation. 

8.2.1.  Interpretation  of  Informal  Advice 

Conversion  of  expertise  into  behavior  involves  translating  informally  expressed  advice  into  a 
precise  representation.  Such  advice  may  contain  constructions  like  “taking  points,"  “lead  a  losing 
heart,”  and  “safe  suit.”  These  constructions  violate  the  well-formedness  property  assumed  in  FOO. 

To  illustrate  this  point,  consider  the  concept  TAKE,  defined  in  FOO  as 
(LAM80A  (P  C)  (MOVE  C  POT  (HAND  P))) 

One  instance  of  this  concept  is  (TAKE  ME  (WINNING-CARD)).  The  mapping  from  the  actual 
arguments  ME  and  (WINNING-CARD)  to  the  lambda  variables  P  and  C  is  positionally  determined  since 
they  are  specified  in  the  same  order,  so  there  is  no  problem  in  identifying  the  arguments  with  the 
lambda  variables. 

Slot-related  information  might  be  useful  in  interpreting  expressions  with  missing  or  mistyped 
arguments.  For  example,  consider  the  informal  construction  (TAKE  POINTS).  Knowing  that  the 
lambda  variable  C  of  TAKE  is  card-valued  and  that  POINTS  is  a  function  on  cards  might  suggest  that 
POINTS  instantiates  C  rather  than  P.  P  might  be  filled  in  by  storing  me  as  its  default  value.  However, 
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further  inference  would  still  be  required  to  interpret  the  informal  input  (TAKE  POINTS)  [Mostow 
79bJ  as 

(TAKE-POINTS  ME)  *  (FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl)) 

The  most  closely  related  research  on  this  problem  is  the  SAFF.  project  [Balzer  77],  involving 
automatic  translation  of  informal  specifications  into  working  code.  The  information  provided  by  an 
actual  task  situation  can  provide  useful  context  for  interpreting  informally  expressed  advice;  for 
instance,  alternative  interpretations  of  ambiguous  advice  can  be  tried  out  in  a  specific  situation  to  see 
which  one  makes  sense  or  leads  to  the  best  outcome  [Balzer  77]. 

8.2.2.  Integration 

Integrating  different  pieces  of  advice  is  a  crucial  and  difficult  problem.  1  simplified  the 
operationalization  problem  addressed  in  FOO  by  assuming  that  advice  could  be  operationalized 
before  integrating  it  with  other  advice.  An  evaluation  function  with  terms  for  each  piece  of  advice 
can  sometimes  be  used  to  integrate  independently  operationalized  advice  [Berliner  79],  Fuzzy 
applicability  conditions  for  each  piece  of  advice  can  be  operationalized  as  coefficients  on  the  various 
terms  [Berliner  79].  A  challenging  problem  that  does  not  appear  to  fit  this  simple  scheme  is  to 
integrate  advice  quantified  over  goals  (§8.2.3)  or  other  pieces  of  advice,  e.g.: 

“Infer  that  a  player  who  did  something  did  it  for  the  same  reason  you  would.” 

8.2.3.  Using  Knowledge  About  Goals 

FOO  lacks  an  explicit  model  of  actors'  goals.  Such  a  model  would  be  very  useful.  For  example,  it 
would  make  it  possible  to  operationalize  advice  of  the  form  ‘To  achieve  X,  do  Y.”  Such  advice  could 
be  used  to  interpret  other  agents’  behavior  based  on  knowledge  about  goals  and  plans; 

Gl.  Assume  another’s  action  is  motivated  by  the  same  reason  you  would  do  it. 

G2.  Assume  the  preconditions  of  a  plan  are  satisfied  if  someone  seems  to  be  following  it. 

G3.  Assume  others  will  pursue  a  goal  using  the  same  plan  you  would. 

Such  knowledge  can  assist  both  evaluation  and  planning.  For  example,  Gl  suggests  that  a  player 
who  leads  spades  is  trying  to  flush  the  Queen.  G2  implies  that  this  player  does  not  have  the  Queen. 

G3  predicts  that  the  player  will  cooperate  in  an  effort  to  keep  leading  spades  until  the  Queen  is 

played.  A  program  that  uses  an  explicit  representation  of  actors’  goal  structures  both  to  plan  and  to  • 
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interpret  behavior  is  described  in  [Carbonell  78].  The  idea  of  an  invertible  representation  supporting 
both  these  uses  is  developed  in  [Hayes- Roth  78a]  and  [Mostow  79bj. 

A  goal  model  would  also  be  required  to  determine  the  implicit  purpose  of  a  piece  of  advice.  For 
example,  a  human  player  who  receives  the  advice  “flush  the  Queen”  will  realize  that  die  purpose  of 
doing  so  is  to  eliminate  the  danger  of  taking  it.  This  ability  could  be  invaluable  both  in  interpreting 
and  integrating  informally  expressed  advice  (§8.2.1)  (§8.2.2).  For  example,  the  advice  “flush  the 
Queen"  could  be  interpreted  as  “flush  the  Queen  without  taking  it”  based  on  an  analysis  of  its 
implicit  purpose;  this  would  prevent  the  mistake  of  leading  the  Ace  to  flush  die  Queen.  Similarly, 
goal-based  analysis  of  “avoid  taking  points"  indicates  that  this  advice  should  be  disregarded  when 
shooting  the  moon.  Building  a  system  to  understand  loosely  phrased  advice  by  relating  it  to  known 
goals  would  make  a  challenging  and  interesting  dissertation  project. 

8.2.4.  Runtime  Mechanism 

The  runtime  mechanism  assumed  in  the  dissertation  is  an  unimplcmented  but  straightforward 
extension  of  LISP  EVAL.  The  basic  extensions  include  the  ability  to  cache  computed  values  [Lenat 
79]  [Marsh  70],  to  try  alternative  partial  definitions,  and  to  exploit  annotations  about  necessary  or 
sufficient  conditions  in  specified  situations  (§2.6.3). 

8.3.  Further  Research  in  AI 

In  developing  too,  I  encountered  some  genera!  representation  problems  of  AI.  These  include 
representation  of  imprecise  concepts  (§8.3.1)  and  of  die  idea  of  knowing  somcdiing  (§8.3.2). 

8.3.1.  Representation  of  Conceptual  Knowledge 

The  power  of  lambda  expressions  for  representing  the  meaning  of  natural  language  is  examined 
in  [Hobbs  78].  The  dissertation  shows  how  to  encode  certain  familiar  classes  of  concepts  (e.g., 
different  kinds  of  adjectives)  as  lambda  expressions  of  appropriate  forms  (§1.3. 1.3).  However, 
abstract  concepts  like  "good”  and  “danger”  remain  difficult  to  encode  in  this  representation.  Doing 
so  appears  to  require  an  explicit  model  of  agents'  goal  structures  (§8.2.3).  For  example,  a  thing  is 
“good"  for  an  agent  whose  goals  it  helps,  and  “dangerous”  for  one  whose  goals  it  threatens.  One  way 
to  avoid  formulating  precise  definitions  for  such  concepts  is  to  use  assertions  and  partial  definitions; 
instead  of  trying  to  find  a  complete  definition  of  “danger",  simply  assert  that  certain  things  arc 
dangerous,  and  relate  dangerous  things  to  other  concepts,  e.g„  “avoid  dangerous  situations.” 
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8.3.2.  Knowledge  about  Knowing 

foo  has  no  explicit  model  of  the  idea  of  an  agent  knowing  a  piece  of  information.  This  is  a  hard 
epistemological  problem  on  which  some  theoretical  work  has  been  done  [McCarthy  77]  but  much 
remains.  Some  model  of  the  "knowing”  relation  is  required  to  encode  and  understand  advice  like 

"Lead  a  suit  to  see  who’s  void  in  it.” 

“Conceal  your  intentions." 


§9.  Conclusion 


359 


Chapter  9 
Conclusion 

This  chapter  places  the  dissertation  in  the  context  of  past,  present,  and  future  research.  (§9.1) 
reviews  prior  research  related  to  operationalization  and  explains  how  it  differs  from  the  work 
reported  here.  (§9.2)  lists  some  important  problems  requiring  further  research.  Finally,  (§9.3) 
evaluates  the  dissertation’s  own  research  contributions  relative  to  the  goals  set  forth  in  (§1). 

9.1.  Related  Research 

This  section  discusses  relevant  prior  research.  (§9.1.1)  defines  some  terms  used  in  this  discussion: 
problem-solving,  constraint  satisfaction,  planning,  and  automatic  programming.  (§9.1.2)  considers 
operationalization  in  terms  of  each  of  these  concepts.  (§9.1.3)  discusses  previous  work  on  the  broad 
problem  of  machine-aided  heuristic  programming,  which  includes  operationalization  as  a  sub¬ 
problem. 

9.1.1.  Problems,  Constraints,  Plans,  and  Programs 

Operationalization  is  closely  related  to  the  often  --  and  loosely  --  used  A1  terms  problem-solving, 
constraint  satisfaction,  planning,  and  automatic  programming.  Intelligent  discussion  of  the 
relationship  among  these  concepts  dictates  an  attempt  to  define  them  first. 

Problem-solving  [Newell  60]  is  a  very  general  term  denoting  the  activity  of  finding  or  constructing 
some  entity  (a  solution)  satisfying  a  given  set  of  requirements  (a  problem).  This  solution  is  the 
intended  result  of  the  problem-solving  process,  Le„  the  purpose  for  undertaking  the  problem-solving 
process;  the  particular  steps  taken  to  reach  it  may  be  of  interest  but  arc  not  part  of  the  solution.  This 
distinction  is  complicated  by  the  fact  that  the  same  problem-solving  activity  can  be  viewed  at  more 
than  one  level.  For  example,  consider  the  problem  of  evaluating  an  expression,  i.e„  tranforming  it 
into  a  constant  that  denotes  the  same  value.  At  this  level,  the  solution  is  the  constant  value  itself. 
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Now  consider  the  problem  of  finding  an  equivalence-preserving  transformation  sequence  from  the 
expression  into  a  constant.  At  this  level,  the  solution  is  the  transformation  sequence. 

Constraint  satisfaction  [Fikes  68]  is  a  particular  kind  of  problem-solving  where  the  problem 
consists  of  a  set  of  assertions  about  (constraints  on)  a  collection  of  variables,  and  a  solution  is  a  set  of 
variable  assignments  satisfying  all  the  constraints. 

Planning  [Sacerdoti  77]  finds  a  sequence  of  actions  (a  plan )  which  when  applied  to  a  specified 
initial  suite  will  produce  a  desired  state  (goal),  represented  as  a  description  of  a  particular  state  or  as  a 
predicate  on  states.  The  initial  suite  is  an  argument  of  the  planning  process,  so  the  plan  need  only 
work  for  that  state.  Typically  the  range  of  possible  actions  is  defined  by  a  given  set  of  state-to-statc 
mappings  (operators).  The  intended  result  of  the  planning  process  is  the  plan,  not  the  final  state. 
This  distinction  can  be  subtle  in  programs  that  solve  problems  by  constructing  and  executing  plans, 
especially  when  plan  construction  and  execution  are  interleaved.  The  overall  activity  constitutes 
problem-solving,  but  only  the  plan  construction  phase,  Le.,  selection  of  an  action  sequence, 
constitutes  planning. 

Automatic  programming  generates  a  program  whose  execution  will  achieve  a  desired  effect,  Le., 
produce  a  state  satisfying  a  desired  relationship  (specification)  with  the  initial  state,  assuming  the 
initial  state  satisfies  a  given  set  of  assumptions  ( precondition ).  The  initial  suite  is  unknown  at  program 
generation  time;  it  is  an  argument  of  the  generated  program,  where  it  is  typically  represented  by  the 
program’s  input  variables.  The  program  must  work  for  any  initial  suite  satisfying  the  precondition. 
In  this  sense,  automatic  programming  is  more  general  than  planning,  although  the  disunction  is 
blurred  in  systems  that  constmct  plans  and  then  generalize  them  [Sacerdoti  77]  (§8.1.7). 

9.1.2.  Prior  Research  Related  to  Operationalization 

Operationalization  is  a  form  of  problem-solving.  In  FOO,  an  operationalization  problem  is  an 
expression  describing  a  goat  to  be  achieved  or  a  quantity  to  be  evaluated  in  the  course  of  performing 
some  cask.  A  solution  is  an  expression  whose  execution  achieves  the  goal  or  computes  the  value  of 
the  quantity. 

Operationalization  is  also  related  to  constraint  satisfaction',  the  thing  to  be  constrained  is  the 
behavior  of  a  runtime  mechanism  performing  a  task,  and  a  constraint  is  a  piece  of  advice  restricting 
this  behavior.  The  task  imposes  further  structure  on  this  behavior  by  making  it  fit  a  specified 
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computational  process,  such  as  the  sequence  of  legal  play  in  Hearts  or  the  left-to-right  generation  of 
tones  in  composing  a  cantus  firtnus.  However,  an  operational  solution  is  more  complex  than  a 
collection  of  variable  assignments. 

Operationalization  in  FOO  can  be  viewed  in  two  very  different  ways  as  planning.  At  the  level  of  the 
task  domain,  the  operators  are  the  actions  the  task  agent  can  perform  and  the  observations  it  can 
make,  the  states  are  task  situations,  and  the  problem  is  to  construct  an  operational  plan  composed  of 
such  actions  to  achieve  a  specified  condition  or  evaluate  a  specified  quantity.  This  differs  from  the 
definition  of  planning  given  above  in  that  the  initial  state  is  not  an  input  to  the  planning  process;  the 
plan  is  supposed  to  work  in  a  variety  of  task  situations.  The  inherent  capabilities  of  the  task  agent 
may  be  quite  limited;  for  example,  a  Hearts  player  cannot  directly  observe  opponents’  cards  or 
control  their  play.  Work  in  problem-solving,  planning,  and  constraint  satisfaction  typically  assumes  a 
single  agent  in  an  environment  where  everydiing  can  be  observed.  Exceptions  include  programs  for 
understanding  goal-based  stories  (Schank  77]  and  international  relations  [Carboncll  78], 

At  the  level  of  the  operationalization  process  itself,  the  states  are  not  task  situations  but 
expressions.  The  initial  state  is  a  non-operational  expression,  and  the  goal  is  to  make  it  operational. 
The  operators  are  FOO’s  transformation  rules.  The  problem  is  to  find  a  rule  sequence  that  transforms 
the  initial  expression  into  an  operational  form.  Such  a  sequence  is  a  plan  for  operationalizing  the 
given  expression,  and  need  not  work  for  any  other.  Operationalization  consists  of  finding  and 
executing  such  a  plan. 

Finally,  operationalization  satisfies  the  above  definition  of  automatic  programming:  the 
specification  describes  a  goal  to  be  achieved  or  a  quantity  to  be  evaluated,  and  the  problem  is  to 
generate  a  program  whose  execution  achieves  tire  goal  or  computes  the  value  of  the  quantity  in  a 
wide  class  of  task  situations.  Both  the  specification  and  the  program  are  represented  as  expressions. 

Several  researchers  in  automatic  programming  have  worked  on  die  problem  of  transforming  an 
abstract  program  specification  into  working  code  [Low  78]  [Barstow  77],  The  specification  is  actually 
a  program  in  a  high-level  language  that  allows  abstract  types,  e.g.,  “set,"  and  corresponding  abstract 
operators,  e.g.,  “union”;  the  language  used  for  this  purpose  in  PSI  actually  had  a  working  (although 
of  course  rather  inefficient)  interpreter  [Green  76j.  Implementing  such  a  specification  can  be  viewed 
is  perationalizing  it  for  a  task  agent  capable  of  interpreting  the  target  language.  It  involves 
-  iiislating  the  abstract  objects  in  terms  of  code-level  primitives,  e.g.,  “linked  list”  and  “append,” 
.  r’i  \mcs  <u  a  process  of  stepwise  refinement  through  intermediate  levels  of  abstraction,  e.g.. 
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This  process  can  be  viewed  as  designing  or  selecting  a  representation  (data  structure  and  associated 
operators)  for  each  abstract  object  in  the  program.  The  efficiency  of  the  implementation  depends  on 
the  cost  of  the  operators  in  the  chosen  representation,  and  on  how  often  they  are  applied  to  each 
object  [Low  78]  [Kant  79],  Korf s  work  [Korf  80]  is  similar  but  translates  a  representation  into 
another  at  the  same  level;  for  example,  "list"  and  "append”  might  be  translated  into  "bit  vector”  and 
"bitwise  OR."  FOO  differs  from  the  work  described  above  in  that  it  lacks  knowledge  about  data 
structures  per  se:  some  of  FOO’s  rules  decide  what  information  to  remember  (§2.4)  (§3.5.3.2),  but  not 
how  to  store  it  (§8.1.5). 

A  key  difference  between  operationalization  and  what  is  usually  called  automatic  programming 
has  to  do  with  the  relationship  between  the  specification  and  the  program  generated  to  satisfy  it.  In 
traditional  automatic  programming,  the  program  must  be  a  correct  implementation  of  the 
specifications,  i.e„  it  must  produce  exactly  the  specified  result  whenever  the  program’s  precondition 
is  satisfied.  In  contrast,  operationalization  produces  an  operational  implementation  that  may  not 
always  produce  the  specified  result,  or  may  produce  an  approximation  to  it  (§1.1).  The  fallible  and 
approximate  methods  permitted  in  operationalization  can  be  used  in  situations  where  the  exact, 
formally  correct  methods  of  automatic  programming  fail.  These  situations  are  typical  of  tasks 
requiring  heuristic  knowledge.  For  example,  no  Hearts  program  can  infallibly  "avoid  taking  points,” 
but  this  advice  can  readily  be  operationalized  ns  "play  a  low  card.” 

9.1.3.  Prior  Research  Related  to  Machine-Aided  Heuristic  Programming 

The  operationalization  problem  formulated  in  this  dissertation  arose  from  the  desire  to  build  a 
general  machine-aided  heuristic  programming  system.  The  various  problems  involved  in  building 
such  a  system  are  described  in  [Haycs-Roth  78a],  and  the  paradigm  is  developed  further  in  [Haycs- 
Roth  80].  The  work  reported  in  this  dissertation  is  related  to  many  other  research  efforts  but  differs 
from  them  in  its  direction. 

Most  automatic  programming  research  has  sought  to  produce  a  program  given  a  formal 
specification  of  its  input-output  relations  and  nothing  else.  The  contrasting  approach  taken  here 
views  operationalization  as  a  part  of  machine-aided  heuristic  programming  (§1).  which  seeks  to 
produce  an  effective  implementation  for  an  informally  specified  task,  given  knowledge  about  the 
domain  of  the  task  and  heuristic  advice  on  how  to  achieve  the  desired  behavior.  This  additional 
knowledge  provides  a  potential  source  of  power  typically  unexploitcd  in  automatic  programming. 
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The  SAFE[Bal/er  77]  and  PS  I  [Green  76]  systems  are  partial  exceptions  to  these  general 
statements  about  formal  input,  domain  knowledge,  and  advice.  PSI  accepted  English  input,  but 
required  problems  to  be  expressed  in  terms  of  rather  formal  built-in  concepts,  such  as  the  notion  of  a 
correspondence.  SAFE  accepted  parenthesized  English  specifications  containing  informality  in  the 
form  of  ambiguity,  implicit  operations  and  operands,  and  imprecise  references.  Both  programs  used 
domain  knowledge.  However,  neither  of  them  were  able  to  accept  heuristic  advice  about  performing 
the  task. 

Various  other  systems  have  been  built  to  accept  informal,  natural  language  task  specifications 
[Davis  77b]  [Heidorn  74]  [Novak  76]  [Simon  77].  These  systems  arc  either  constrained  to  a  single 
domain  or  limited  to  a  shallow  understanding  of  their  input.  The  specifications  they  accept  are 
statements  about  the  task,  not  general  advice  about  how  to  perform  it. 

The  idea  of  an  advice  taker  has  been  around  for  some  time.  In  [McCarthy  68],  "advice”  consisted 
of  useful  facts  encoded  as  logical  axioms  to  be  used  by  a  theorem-prover  in  the  formal  derivation  of  a 
plan.  In  contrast,  machine-aided  heuristic  programming  focuses  on  accepting  informal  heuristics  and 
using  them  to  guide  task  behavior. 

Exemplary  programming  [W atermaa  78)  seeks  to  infer  a  general  algorithm  for  solving  a  problem  by 
observing  how  to  solve  it  in  one  or  more  specific  instances,  without  understanding  what  die  problem 
is.  Machine-aided  heuristic  programming  uses  both  a  description  of  what  is  desired  and  advice  about 
how  to  achieve  it  [Hayes-Roth  78a]  [Mostow  78]. 

A  growing  body  of  research  is  concerned  with  learning  general  principles  from  examples  [Buchanan 
78]  [Hayes-Roth  78c]  [Dietterich  81][Vcre  78],  observations  [Soloway  77],  and  experience  [Lcnat 
78]  [Mitchell  77]  [Waterman  70].  In  contrast,  machine-aided  heuristic  programming  is  a  form  of 
learning  by  being  told ,  or  more  precisely,  learning  by  discovering  how  to  do  what  you  ’re  told:  it  seeks  to 
apply  such  principles  once  they  have  been  described  by  an  expert. 

Heuristic  programming  seeks  to  achieve  expert  performance  on  a  task  by  incorporating  in  a 
program  the  knowledge  of  an  expert  practitioner  [Bal/.cr  66]  [Buchanan  78]  [Buchanan  69]  [Carnegic- 
McllonUniversity  77]  [Davis  77a]  [Duda  78]  [Fcigcnbaum  77]  [Grccnblatt  67][I.cnat  78]  [Martin 
77]  [Stcfik  80],  Such  knowledge  engineering  typically  uses  a  human  programmer  as  the  interface 
between  the  expert  and  the  computer.  This  interface  has  high  latency  time  and  low  bandwidth:  it 
can  take  a  considerable  amount  of  initialization  for  the  expert  and  the  programmer  to  develop  a 
common  vocabulary,  and  the  rcimplcmcntation  cost  of  modifying  the  program  to  incorporate 
additional  knowledge  is  often  prohibitive. 
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This  knowledge  assimilation  bottleneck  has  motivated  efforts  to  develop  systems  which  can 
communicate  with  experts  in  terms  of  their  own  domain  concepts  [Nii  79)  [Davis  77b)  [Hewitt 
75)  [Martin  77]  [Zobrist  73).  So  far,  the  only  such  systems  are  either  domain-specific  or  very  limited 
in  the  form  of  knowledge  they  can  accept,  e.g„  MYCIN-stylc  rules  and  MOLGEN  units  rather  than 
arbitrary,  informally  expressed  suggestions  about  the  system’s  own  problem-solving  behavior.  The 
machine-aided  heuristic  programming  approach  seeks  to  extend  the  form  and  range  of  knowledge 
such  a  system  can  accept. 

Several  existing  programming  languages  are  extensible.  However,  new  constructs  must  be  defined 
by  procedural  composition  of  old  ones,  and  the  details  of  the  composition  must  be  explicitly  spelled 
out.  The  goal  of  machine-aided  heuristic  programming  is  to  allow  experts  to  communicate 
infonnally  in  terms  of  domain  concepts,  without  having  to  specify  the  details  involved  in  applying 
one  concept  to  another,  rather  than  having  to  code  their  knowledge  in  a  formal  language. 

It  should  be  emphasized  that  this  dissertation  is  not  about  game-playing  programs.  In  fact,  TOO 
lacks  the  mechanisms  required  to  actually  play  a  game  of  Hearts  or  compose  a  can tus  firinus,  since 
doing  so  was  unnecessary  for  the  purposes  of  the  dissertation.  Hearts  was  simply  an  experimental 
vehicle  well-suited  to  investigating  the  general  phenomena  of  interest.  However,  two  game-playing 
programs  seem  relevant.  The  General  Game  Playing  Program  [Williams  72)  is  sometimes  described 
as  taking  advice  about  how  to  play.  GGPP  was  a  high-level,  game-oriented  programming  language 
with  a  general  matcher  for  finding  instances  of  game  patterns  defined  in  terms  of  built-in  primitives. 
Input  to  GGPP  consisted  of  a  game  description  and  an  algorithm  (not  advice)  for  how  to  play  it. 
Waterman’s  poker  program  [Waterman  70)  improved  its  performance  based  on  feedback  from  the 
results  of  applying  its  productions  for  bidding:  one  might  view  such  feedback  as  advice.  However, 
the  poker  task  was  built  into  the  program  rather  than  input  to  it,  and  the  program  could  only  learn 
productions  expressed  in  terms  of  range  restrictions  on  built-in  variables. 

9.2.  Problems  for  Future  Research 

F'OO  addresses  a  small  part  of  a  large  problem  whose  solution  calls  for  many  additional  techniques 
and  sources  of  knowledge.  (§8)  describes  some  of  the  remaining  problems  and  proposes  detailed 
approaches  to  them;  these  problems  are  summarized  briefly  below. 

Many  kinds  of  operationalization  knowledge  are  used  in  the  construction  of  intelligent  programs, 

e.g.: 
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Operationalization  strategies 
AI  weak  methods 
Analysis  techniques 
Knowledge  about  data  structures 

FOO  represents  only  a  tiny  fraction  of  this  large  body  of  knowledge.  Formalizing  such  knowledge 
and  encoding  it  in  a  form  suitable  for  mechanical  application  will  require  considerable  work.  In 
particular,  the  purely  analytic  approach  embodied  in  FOO  should  be  considerably  enriched  by 
exploiting  empirical  methods  and  sources  of  information  not  used  in  FOO  (§8.1.7). 

Operationalization  is  closely  related  to  other  problems  involved  in  machine-aided  heuristic 
programming,  many  of  which  have  received  attention  from  other  researchers: 

Interpret  informal  input 
Integrate  multiple  goals 
Understand  goal-oriented  behavior 

These  connections  arc  not  addressed  in  FOO  but  should  be  explicitly  considered  in  future  research. 
Building  a  practical  machine-aided  heuristic  programming  system  will  require  formalizing  and 
encoding  a  large  repertoire  of  techniques  used  in  natural  language  understanding,  knowledge 
engineering,  and  program  design,  but  if  successful  will  provide  a  corresponding  large  productivity 
payoff  in  the  development  of  intelligent  programs. 

9.2.1.  Some  Interesting  Dissertation  Topics 

Several  of  the  problems  described  above  would  make  interesting  dissertation  projects: 

Interpret,  operationalize,  and  integrate  advice  in  terms  of  the  goals  it  explicitly  mentions  or  implicitly 
affects  (§&. 2.3).  For  example,  infer  that  the  purpose  of  the  advice  “flush  the  Queen"  is  to  remove  the 
danger  of  taking  it,  and  fill  in  the  missing  qualifier:  “flush  the  Queen  without  taking  it."  Similarly, 
infer  that  the  purpose  of  the  advice  “get  void”  is  to  enable  sluffing  (discarding  dangerous  cards)  when 
the  suit  is  led;  use  this  knowledge  to  discount  the  desirability  of  getting  void  in  a  suit  unlikely  to  be 
led.  Finally,  operationalize  vague  terms  —  like  “dangerous"  and  "desirable"  in  the  preceding 
sentence  -  as  implicit  references  to  whatever  goals  arc  relevant  in  the  current  task  situation. 


Represent  A  l  methods  in  a  form  conducive  to  their  mechanical  application.  The  formulate-and' 
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refine  approach  appears  promising.  Tappcl  has  devised  some  general  algorithm-improving  operators 
represented  as  local  transformations  on  data  flow  graphs  P'appcl  80],  This  work  should  be  combined 
with  refinement  techniques  based  on  domain  knowledge  and  analysis  like  those  described  in  the 
dissertation  (§3.4). 

Automate  the  control  of  the  operationalization  process  (§8.1.1).  Means-end  analysis  looks  like  a 
good  approach  to  the  problem-solving  issues  avoided  in  FOO  (§7).  A  fruitful  research  plan  might  aim 
first  at  automatic  application  of  high-level  operationalization  strategics  selected  by  a  user,  perhaps 
from  a  machine-generated  list  of  suggestions.  If  enough  of  the  problem-solving  can  be  automated, 
’nteractivc  operationalization  could  prove  useful  as  a  knowledge  engineering  technique.  Fully 
automatic  operationalization  will  require  additional  research,  such  as  the  development  of  a  model  of 
runtime  task  capabilities. 

Learn  concept  features  (like  reflexivity  (§5.3))  and  semantic  relations  among  concepts  (like 
homomorphisms  (§6.1.2))  and  develop  analysis  methods  to  exploit  them.  Such  methods  can  quickly 
make  inferences  about  an  expression  that  would  otherwise  require  cumbersome  analysis  based  on 
expanding  its  definition  in  terms  of  primitive  entities.  The  properties  they  exploit  could  be  learned 
by  a  combination  of  empirical  observation  [Lenat  78]  and  analysis  of  the  task  description  and  concept 
definitions  (§8.1.7).  Possibly  the  concept  properties  and  analysis  methods  would  feed  on  each  other, 
with  new  properties  enabling  further  analysis  enabling  the  discovery  of  higher-level  properties. 

Automate  the  acquisition  of  operationalization  strategies.  What  inferences  can  be  made  upon 
receiving  the  definition  of  a  new  concept,  e.g..  suit  distribution,  that  will  enable  it  to  be  used  in 
operationalizing  advice  (§6.5.5)?  How  can  an  operationalization  strategy  be  refined  based  on  the 
experience  of  trying  to  use  it  (§8.1.7)?  Just  as  the  conversion  of  task  heuristics  into  task  performance 
is  a  bottleneck  in  the  construction  of  intelligent  task  agents,  the  acquisition  of  operationalization 
knowledge  may  prove  a  bottleneck  in  the  construction  of  intelligent  operationalizers.  and  therefore 
equally  deserving  of  mechanical  assistance.  * 

9.3.  Evaluation 

The  appropriate  criterion  for  evaluating  the  dissertation  is  how  well  it  supports  its  thesis  (§1.1.3): 

There  exist  general  operationalization  methods  that  can  be  stated  independently  of  any  specific 
task  domain  although  applying  them  generally  requires  domain- specif  c  knowledge. 
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The  strategy  used  to  gather  evidence  for  this  thesis  was  to 

Represent  a  diverse  set  of  general  operationalization  methods  and  apply  them  mechanically. 

The  dissertation  research  should  therefore  be  judged  according  to  die  following  criteria: 

1.  The  formal  representation  of  methods  in  FOO  (§9.3.1) 

2.  The  diversity  of  FOO’s  methods  (§9.3.2) 

3.  The  generality  of  FOO’s  methods  (§9.3.3) 

4.  The  mechanical  applicability  of  FOO’s  methods  (§9.3.4) 

In  particular,  coverage  is  not  an  appropriate  evaluation  criterion.  The  goal  of  encoding  a  broad 
collection  of  methods  is  a  very  ambitious  one,  and  the  dissertation  only  scratches  the  surface.  Gcarly 
there  exist  many  general  operationalization  methods  besides  those  encoded  in  FOO;  extrapolation 
from  FOO  suggests  that  it  should  be  possible  to  encode  others  in  a  similar  manner. 

There  are  other  perspectives  from  which  the  dissertation  can  be  evaluated.  From  the  broad 
perspective  of  knowledge  engineering,  it  should  be  judged  by  its  contributions  toward  the  goal  of 
building  a  machine-aided  heuristic  programming  system.  The  feasibility  of  this  goal  has  been  argued 
elsewhere  [Hayes-Roth  78a].  The  representation  and  mechanical  application  of  operationalization 
methods  in  FOO  provide  evidence  for  the  feasibility  of  an  important  subgoal:  automatic 
operationalization.  Many  of  the  other  problems  involved,  such  as  interpretation  of  informal  natural 
language  input,  have  received  attention  from  other  researchers  [Balzer  77],  Prototypes  of  the 
machine-aided  heuristic  programming  paradigm,  with  hand  simulation  of  some  of  the  inference 
processes,  have  been  built  to  acquire,  apply,  and  refine  knowledge  in  various  task  domains  [Hayes- 
Roth  80], 

Psychological  validity  is  not  a  necessary  condition  for  the  success  of  the  dissertation,  but  certain 
aspects  of  FOO  are  by  design  consistent  with  psychological  intuition.  In  particular,  some  of  the 
derivations  incorporate  a  solve-and- refine  strategy  I  observed  in  my  own  behavior  when 
operationalizing  advice  by  hand:  a  crude  initial  solution  is  contructcd  and  then  refined  by  taking 
more  information  into  account  (§2.3. 1.5)  (§3.4),  for  example  by  searching  the  knowledge  base  for  a 
concept  of  a  specified  form.  Given  a  mechanism  for  performing  such  a  search,  the  ability  to  solve  a 
particula.  kind  of  problem  can  be  dramatically  improved  just  by  acquiring  a  suitable  concept  in  terms 
of  which  to  view  the  problem  (§6.5.5).  This  suggests  a  way  for  systems  to  extend  their  range  of 
competence  simply  by  being  told  new  ideas,  an  intelligent  trait  sometimes  exhibited  by  humans. 
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9.3.1.  Formal  Representation  of  Operationalization  Methods 

The  formal  representation  of  various  methods  for  operationalization  and  analysis  is  a  central 
contribution  of  the  dissertation.  In  particular,  it  formalizes  certain  classes  of  operationalization 
problems  as  equations  and  identifies  some  analysis  methods  useful  in  solving  them: 

1.  e  =  . x  ))  --  reformulate  e  in  terms  of  concept  f  (§4.2) 

2.  e  =  A(v)  --  reformulate  e  as  a  function  of  quantity  v  (§4.2) 

3.  d  =  Dv(c)  --  approximate  e  as  a  function  of  quantity  v  (§2.8) 

4.  P  =>  Q  -  find  a  necessary  condition  for  P  (§2.6) 

5.  Q  =>  P  --  find  a  sufficient  condition  for  P  (§2.6) 

The  unknowns  arc  shown  in  italics.  Note  that  the  unknown  h  in  equations  1  and  2  is  a  function;  it 
represents  the  relationship  to  be  found  between  two  givens. 

The  formalization  of  reformulation  problems  and  techniques  for  their  solution  extends  previous 
work  on  multiple  views :  "reformulating  e  in  terms  of  concept  f’  can  be  called  "viewing  e  as  an  f." 
Such  work  has  primarily  addressed  the  problem  of  representing  different  perspectives  on  an 
entity  [Brachman  79].  Efforts  at  inferring  a  perspective  --  figuring  out  how  to  view  an  X  as  a  Y  --  have 
largely  relied  on  heuristic  matching  and  inheritance  mechanisms  {Moore  74]  [Bobrow  77].  In 
contrast,  FOO  formalizes  the  problem  of  viewing  one  concept  as  another,  provides  analytic  methods  for 
discovering  a  relationship  between  them  based  on  their  definitions,  and  explicitly  represents  both  the 
relationship  and  the  assumptions  made  in  the  course  of  deriving  it. 

The  dissertation  identifies  general  scenarios  for  applying  certain  operationalization  strategics  and 
analysis  methods,  including: 

Problem  separation  (§5.7) 

Finding  a  necessary  or  sufficient  condition  (§2.6.4.1) 

Partial  matching  (§5.3.1) 

Heuristic  search  (§3.3) 

These  scenarios  reduce  a  series  of  differences  between  an  initial  problem  and  the  problem 
statement  of  the  particular  method  until  the  method  can  be  applied;  some  scenarios  incorporate  a 
subsequent  phase  in  which  a  crude  initial  solution  is  refined  (§1.6). 

The  dissertation  contributes  to  the  understanding  of  various  existing  analysis  methods  (c.g.,  partial 
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matching  (§5.3)  [Hayes-Roth  78b])  by  representing  them  in  a  common  transformational  paradigm. 
This  uniform  model  for  the  description  of  different  problem-solving  methods  should  help  future 
researchers  to  elucidate  the  logical  status  of  various  methods  (§5.11)  and  to  combine  them  in  solving 
problems. 

In  addition,  the  dissertation  extends  some  previously  described  methods.  For  example,  a 
previously  described  calculus  of  functional  dependence  [DcKleer  79]  is  augmented  to  include  a 
multiplication  operator  based  on  the  chain  rule  for  differentiation  (§2.8). 

9.3.2.  Diversity  of  Operationalization  Methods 

The  diversity  of  roo’s  methods  must  be  evaluated  subjectively  by  inspection.  These  methods  can 
be  viewed  as  experimental  vehicles:  encoding  each  new  method  in  FOO  tested  the  adequacy  of  the 
transformational  paradigm.  The  representational  scope  of  this  paradigm  is  illustrated  by  the  diverse 
methods  applied  to  the  problem  of  deciding  whether  an  opponent  is  void: 

Inference  from  observed  behavior  (§2.6.2) 

Recollection  of  previous  conditions  (§2.4.2) 

Probabilistic  analysis  (§2.3) 

Functional  approximation  (§2.8.2). 

Some  additions  to  the  paradigm,  including  schemas  (§3.2)  and  global  variables  (§5.4),  were  needed 
in  order  to  accommodate  some  of  the  methods.  By  and  large,  however,  the  diversity  of  the  encoded 
methods  supports  the  adequacy  of  the  paradigm  as  a  problem  space  for  operationalization,  and 
suggests  that  many  other  methods  could  be  encoded  in  POO  without  significantly  altering  this 
paradigm. 

9.3.3.  Generality  of  Operationalization  Methods 

The  generality  of  roo's  methods  must  primarily  be  evaluated  by  inspecting  their  representation  as 
rules  expressed  in  domain-independent  terms,  since  it  was  not  feasible  within  the  scope  of  the  project 
to  test  them  on  a  large  number  of  problems  drawn  from  a  wide  variety  of  task  domains.  Except  for  a 
few  “fact  rules"  used  to  simulate  unimplemcnted  mechanisms.  FOO  clearly  separates: 


General  knowledge  about  operationalization  and  analysis  -  expressed  as  transformation  rules 
Specific  knowledge  about  task  domains  -  expressed  mostly  as  concept  definitions 
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Inheritance  knowledge  --  expressed  as  is-a  hierarchy,  used  to  apply  general  rules  to  specific 
concepts 

In  a  few  cases,  generality  was  explicitly  demonstrated  by  applying  the  same  operationalization 
strategy  to  apparently  dissimilar  problems.  For  example,  the  set  depletion  method  (§2.5)  was  used  to 
operationalize  both  “get  void"  and  “flush  the  Queen.”  Similarly,  both  the  Hearts  advice  “avoid 
taking  points”  and  the  music  task  "compose  a  cantus  firmus”  were  operationalized  as  heuristic  search 
problems,  using  substantially  the  same  rules  for  formulating  and  refining  a  heuristic  search  (§3.6). 

Unlike  the  operationalization  strategies,  many  of  FOO’s  analysis  rules  were  used  more  than  once, 
and  several  proved  useful  in  both  task  domains.  Appendix  B.2  shows  the  skewed  distribution  of  rule 
use  in  the  derivations:  most  rules  were  used  only  once,  many  were  used  more  often,  and  a  few  were 
used  many  times. 

9.3.4.  Mechanical  Applicability  of  Operationalization  Methods 

The  mechanical  applicability  of  the  operationalization  strategies  encoded  in  FOO  was  demonstrated 
by  mechanically  applying  each  one  to  one  or  more  problems.  This  required  encoding  analysis 
methods  (§5)  and  domain  knowledge  (§6),  which  in  fact  comprise  most  of  FOO.  The  amount  of 
analysis  and  domain  knowledge  required  to  implement  general  operationalization  strategics  is 
discussed  further  below. 

9.3.4.1  Operationality  of  Operationalization  Methods 

The  concept  of  operationality  can  be  applied  to  operationalization  methods  themselves. 
Operationalizing  a  piece  of  advice  like  “avoid  taking  points”  means  figuring  out  how  to  apply  it  to 
actual  task  situations,  i.a,  choosing  a  card  to  play.  Similarly,  operationalizing  a  general 
operationalization  method  means  figuring  out  how  to  apply  it  to  actual  operationalization  problems. 
For  example,  consider  the  following  strategy  (§2.6): 

Find  an  evaluable  necessary  condition  for  an  unevaluable  predicate  P. 

Formalizing  this  strategy  as  “solve  P  =>  Q  for  Q"  is  not  enough  to  make  it  operational;  applying  it 
requires  the  ability  to  solve  such  an  equation,  for  example  by  elaboration,  restructuring,  partial 
matching,  and  simplification  (§2.6.4.1). 

Just  as  the  operationality  of  a  piece  of  advice  depends  on  the  capabilities  of  the  runtime 
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mechanism,  the  opcrationality  of  a  general  operationalization  method  depends  on  the  analytic  power 
of  the  operationalization  engine.  In  particular,  this  engine  must  be  able  to 

1.  Map  a  specific  operationalization  problem  onto  the  general  method. 

2.  Test  any  conditions  required  by  the  method. 

3.  Implement  any  decisions  made  by  the  method. 

The  more  general  the  method,  the  more  apparatus  seems  to  be  needed  to  make  it  operational. 
Perhaps  this  explains  why  so  much  of  FOO  consists  of  apparatus  supporting  a  rather  small  number  of 
operationalization  methods.  The  contribution  of  the  dissertation  lies  not  so  much  in  the  specific  set  of 
methods  implemented  as  in  the  demonstration  of  how  such  methods  can  be  represented  and 
mechanically  applied,  and  in  the  investigation  of  the  apparatus  needed  to  support  them. 

9.3.5.  Towards  the  Automation  of  AI 

The  original  goal  of  this  research  was  to  encode  knowledge  about  AI  in  a  form  suitable  for 
mechanical  application.  What  methods  are  used  in  AI?  What  reasoning  is  required  to  apply  them  to 
a  given  problem?  How  can  general  methods  use  knowledge  about  a  specific  task  domain? 

This  scientific  goal  stands  on  its  own,  independent  of  the  knowledge  engineering  goal  of  building  a 
machine-aided  heuristic  programming  system.  F.vcn  if  such  a  system  were  infeasible,  these  questions 
would  still  deserve  attention  and  the  answers  provided  by  the  dissertation  are  a  key  part  of  its 
contribution. 

Unsurprisingly,  the  goal  turned  out  to  be  quite  hard.  TOO  encodes  only  a  few  operationalization 
methods,  some  of  which  appear  almost  trivially  simple,  e.g.,  “to  empty  a  set.  remove  its  elements  one 
by  one"  (§2.5).  The  most  sophisticated  method  represented  is  heuristic  search  (§3).  Most  of  roo’s 
rules  are  included  to  support  such  methods,  by  helping  to: 

1.  Map  a  problem  to  a  method. 

2.  Solve  subproblcms  generated  by  the  method. 

3.  Transform  method  results  into  a  usable  form. 

This  appears  to  be  an  inherent  feature  of  building  intelligent  programs:  some  general  AI  methods 
arc  used,  but  most  of  the  work  consists  of  figuring  out  how  to  fit  problems  into  the  right  form  and 
implement  decisions  dictated  by  the  methods.  This  requires  both  knowledge  about  die  task  domain 
and  a  substantial  amount  of  general  analytical  reasoning.  Although  other,  more  empirical  approaches 
might  lead  to  a  different  view,  the  derivations  generated  using  t  oo  suggest  that 
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Reformulation  is  the  central  process  in  operationalization. 

While  machine  understanding  of  AI  is  an  ambitious  goal,  the  progress  reported  in  this  dissertation 
suggests  that  it  is  both  feasible  and  worthwhile.  Translation  of  heuristic  knowledge  into  task 
performance  is  already  a  bottleneck  in  the  development  of  intelligent  programs.  As  these  programs 
grow  in  size  and  complexity,  the  importance  of  mechanical  assistance  in  their  construction  can  only 
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Appendix  A 
Task  Descriptions 


This  appendix 


describes  the  Hearts  and  music  tasks  used  as  vehicles  for  exploring 


operationalization  issues  with  FOO. 


A.l.  Rules  of  Hearts 


(The  following  description  of  the  rules  of  Hearts  is  adapted  from  [Baker  66].) 

1.  The  game  is  three-handed,  seventeen  cards  being  deak  to  each  player  and  one  card,  the  hole 
card,  being  placed  face  down  in  the  center  of  the  table. 

2.  The  person  to  the  left  of  the  dealer  leads  and,  if  possible,  each  player  must  follow  suit.  If  he  has 
no  cards  in  the  suit  led  ("is  void”),  he  may  discard  any  card  from  his  hand  (“break  suit").  The 
person  playing  the  highest  card  of  the  suit  led  wins  the  trick  and  leads  for  the  next  trick. 

3.  The  person  taking  in  the  first  trick  gets  the  hole  card,  which  he  alone  gets  to  sec.  He  must  state 
whether  or  not  the  hole  card  is  a  heart 

4.  Hearts  may  not  be  led  until  they  have  been  discarded,  the  leader  has  nothing  else  in  his  hand, 
or  the  hole  card  is  a  heart 

5.  The  score  is  evaluated  as  follows: 

a.  One  point  to  the  bad  for  each  heart  taken  on  any  trick. 

b.  Thirteen  points  to  the  bad  if  the  Queen  of  spades  is  taken  on  any  trick. 

c.  Ten  points  to  the  good  if  the  Jack  of  diamonds  is  taken. 

d.  If  the  Queen  of  spades  and  all  13  hearts  arc  taken  by  one  player,  each  of  the  other  players 
gets  twenty-six  points  to  the  bad.  This  is  termed  "shooting  the  moon." 

6.  Before  the  first  lead,  each  player  passes  four  cards  to  the  person  on  his  left,  these  cards  thus 

*  becoming  part  of  the  next  person's  hand. 

7.  The  game  ends  as  soon  as  any  player  “goes  out”  by  accumulating  100  points  (or  some  other 
score  agreed  on  before  the  game).  The  player  with  the  lowest  score  wins  the  game. 

*  FOO’s  knowledge  about  the  rules  of  Hearts  is  encoded  in  the  definitions  of  trick  and 
LEGAL  (§C.3). 
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Derivations  DERIV2  (§D.2)  through  DERIV12  (§D.12)are  based  on  the  following  Hearts  advice: 
Avoid  taking  points  (§D.2)  (§D.6). 

If  the  Queen  of  spades  is  out,  flush  it  (§D.3)  without  taking  it  yourself  (§D.S). 

Don’t  lead  a  high  card  in  a  suit  where  an  opponent  is  void. 

Get  the  lead  (§D.7). 

Get  void  (§D.8). 

Operationalizing  these  goals  generates  some  evaluation  problems: 

Decide  if  die  Queen  is  out  (§D.4). 

Decide  if  an  opponent  is  void  (§D.9)  (§D.ll)  (§D.12). 

Count  the  number  of  cards  out  in  a  suit  (§D.10). 

A.2.  Cantus  Firmus 

A  canius  firmus  is  a  sequence  of  whole  notes  satisfying  certain  musical  constraints.  DERIV13  and 
DERIV14  operationalize  some  of  these  constraints  for  a  left-to-right  tone  sequence  generator,  i.e.,  as 
tests  that  depend  only  on  the  notes  generated  so  far  and  the  note  about  to  be  generated. 

These  constraints  were  selected  from  a  couple  of  dozen  given  in  a  music  composition 
textbook  [Salzer  69],  which  Meehan  incorporated  in  his  cantus  generation  program  [Meehan  72], 

The  constraints  used  in  TOO  arc  shown  below  along  with  the  concepts  in  terms  of  which  they  arc 
expressed: 

Cl.  A  cantus  is  usually  between  8  and  16  notes  long. 

(IN  (#  CANTUS)  (LB :UB  8  16)) 

C2.  Dissonant  leaps,  chromatic  half  steps,  and  intervals  greater  than  an  octave  are  not  allowed. 

(FORALL  Y  (INTERVALS-OF  CANTUS)  ( USABLE- INTERVAL  1  Y))] 

(INTERVALS-OF  S)  =  (EACH  I  (L8:UB  1  [-  (#  S)  1]) 

(INTERVAL  [S  I]  [S  (+  I  1)])) 

(USABLE -INTERVAL  1  Y)  =  (NOT  (OR  [CHROMATIC-HALF-STEP  1  Y] 

[DISSONANT-LEAP!  Y] 

[OCTAVE-*- !  Y]) ) 

(CHROMATIC-HALF-STEP!  Y)  *  (=  (SIZE  Y)  (MINOR  2)) 
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(LEAP!  Y)  =  (>  (SIZE  Y)  (MAJOR  2)) 

(DISSONANT-LEAP!  Y)  =  (OR  [SEVENTH!  Y]  [AUGMENTED!  Y]  [DIMINISHED!  Y]) 
(FILTER  (INTERVALS)  USABLE-INTERVAL!)  =  (SET  m2  M2  m3  M3  P4  P5  m6  M6  P8) 

C3.  The  range  of  the  cantus  should  not  exceed  a  major  tenth. 

(*<  (MELOOIC-RANGE  CANTUS)  (MAJOR  10)) 

(MELODIC-RANGE  S)  =  (SIZE  (INTERVAL  (LOWEST  S)  (HIGHEST  S))) 

C4.  The  climax  note  of  the  cantus  should  not  be  repeated. 

(=  (OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  1) 

(CLIMAX  S)  =  (HIGHEST  S) 

(OCCURRENCES  N  S)  *  (#  (SET-OF  X  S  (=*  X  N))) 

l'he  informality  in  the  last  definition  arises  from  quantifying  over  the  sequence  S  as  though  it  were 
a  set  (§2.11.1.1). 
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Appendix  6 
Transformation  Rules 


This  appendix  places  FOO’s  rules  in  a  taxonomy  (§B.l),  shows  how  often  different  rules  are  used  in 
the  derivations  (§B.2),  describes  how  FOO  interprets  transformation  rules  (§13.3),  and  lists  them  in  a 
precise  machine-generated  notation  (§  B.4). 


B.I.  Rule  Taxonomy 

Hie  following  taxonomy  of  roo's  rules  for  the  most  part  follows  the  classifications  used  in  the  text. 
Some  rules  appear  under  more  than  one  classification.  The  top-level  categories  are: 

1.  Analysis  rules  (§5) 

2.  Control  rules  for  subgoaling  and  global  communication  (§5.4) 

3.  Domain-specific  facts  (§1.3.3) 

4.  Operationalization  strategics  (§2) 

5.  Translation  mles  (§5.8) 


The  rules  are  shown  in  their  entirety  in  Appendix  B.4;  the  abbreviated  versions  in  parentheses  are 
intended  to  suggest  the  nature  of  each  rule  by  showing  the  flattened  list  of  literal  (non-variable) 
symbols  contained  in  its  left-  and  right-hand  side,  without  regard  to  list  structure. 


RECORD  FILE  OSK :  (RLT319  .  QZG)  OPENED  20-MAR-81  18:22:48 
NIL 

<73>p-f  any-rule 

ANY -RULE: 

ANA1 YStS-RULE : 

ACrtON-RULE:  RULE254  (CHANGE  ->  ACTION) 

RULE339  (■  CHOOSE  ->  ■  SET) 

RULE353  (HOT  -  -  ME ) 

RULE358  (CAUSE  AT  ->  MOVE) 

RULE368  (UNDO  AT  ->  MOVE) 

EXAMPLE-RULE:  RULE84  (FIND-ELT  ->  SCONSTANT!) 

RULE109  (NOT  AND  FORALL  ->  •>  AND  NOT  FIND-ELT) 

RULE  142  (PREDICATE  FIND-ELT  ->  AND  IN  PREDICATE) 
RULE347  (EXISTS  SCONSTANT!  -V  PREDICATE  SCONSTANTI) 
RUIE364  (IN  SUNOOUND-VAR!  PROJECT  ->  T) 
FUNCTIONAL-DOMAIN-RUIE:  RULE  195  (OOMAIN  ->  DOMAIN) 
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RULE  196  (DOMAIN  SUNARY  I  ->  DOMAIN) 

RULE  197  (DOMAIN  SUIT-OF  ->  CARDS) 

FUNCTIONAL -RECURRENCE -RULE :  RULE 2 1 1  (*  SUNBOUNO-VAR!  ->  ■  JUNBOUND-VAR !  LAMBDA) 

RULE212  (■  SUNBOUND- VAR  I  ->  *  SUNBOUNO-VAR !  INVCRSE  LAMBDA) 
RULE315  (REFORMULATE  ->  LAMBDA) 

FUNCTIONAL-RULE : 

D£ FUNCTIONALIZE -RULE :  RULE273  (SUNAPPLIEDI  ->  ?) 

FUNCTIONALIZE-RULE:  RULE297  (BOOLEAN-OP  ->  BOOLEAN-OP-SFUNCTIONAL I ) 

RULE298  (NOT  ->  NOT-JFUNCTIONAL I ) 

RULE305  (ANY-CONCEPT  ->  ANY-CONCEPT) 

RUL  E 393  (LAMBDA  FUNCTION  ->  FUNCTION  LAMBDA) 

INTERSECTION -SEARCH-RULE:  RULE57  (DURING  ->  NIL) 

RULE  199  (COMMON-SUPERSET  SET-OF  SET-OF  ->  ?) 

RULE308  (CHOICE-SEQ-OF  ->  NIL) 

PARTIAL-MATCH-RULE:  RULE30  (TRANSITIVE  SSET!  ->  SUBSET  SSET!) 

RULF43  (REFLEXIVE  ->  AND  ■) 

RUIE91  (REFLEXIVE  ->  AND  ■) 

RULE  172  (IN  PROJECT  ->  IN) 

RULE  192  (*  QUANTIFIER-PREDICATE  QUANTIFIER-PREDICATE  ->  -) 

RULE322  («>  EXISTS  -)  AND  IN  ■) 

RULE379  (->  FORALL  FORALL  ->  SUBSET) 

RULE380  (*  FORALL  FORALL  ->  *  OR  IN  DIFF) 

RULE388  (SUBSET  SET-OF  SET-OF  ->  SUBSET) 

PROBI  EM-MERGING  RULE  :  RULE297  (BOOLEAN-OP  ->  BOOLEAN-OP-SFUNCTIONAL 1 ) 

RULE360  (AND  ACHIEVE  ->  ACHIEVE  AND) 

PROBLEM-REOUCTION-RULE : 

HEURISTIC-EQUIVALENCE -PRESERVING -RULE:  RULE2I3  (LAMBDA  ->  7) 

RUL £2 15  (LAMBDA  ->  7) 

RULE290  (NUMERICAL-PREDICATE  *■  SCONSTANTI 
SCONSTANT!  ->  NUMERICAL-PREDICATE 
SCONSTANT! ) 

RULE374  (BEFORE  BOOLEAN  SCONSTANT!  -> 
BOOLEAN -SCONSTANT ! ) 

REDUCE -7NEC-COND-RULE :  RULE350  (ACHIEVE  AND  ->  ACHIEVE  AND) 

RULE354  (ANO  ■  ->  AND) 

RULE369  (IN  SET-OF  ->  ?) 

REDUCE -XNON-FQUIVALENT-RULE:  RULE238  (CHOOSE  ->  7) 

RULE366  (ACHIEVE  PREVIOUS  ->  ACHIEVE) 

REDUCE -7SUFE-CONO  RULE:  RULE  193  (•  IN  SVAR!  ->  ■  SET-OF  $VAR!  DOMAIN  SVAR!) 

RULE224  (=>  ANO  ->  *>) 

RULE225  (■>  OR  ->  AND  NOT  OR  ■>) 

RULE226  (*>  *>  ->  ANO  ■>) 

RULE277  (CHANGE  EXTREME  ->  COMPARATIVE  EXTREME  CHANGE 
EXTREME) 

SPECIAL -CASE-REDUCTION-RULE:  RULE  19  (OIFF  JOIN  >  JOIN) 

RULE300  (NEXT  EXTREME  ->  EXTREME  CHANGE) 

RULE303  (SET-OF  ->  NIL) 

RUIF324  (»  EXTREME  EXTREME  ->  IN  EXTREME) 

RUIE325  (•  ->  IN  INDTCFS-OF) 

RU1E362  (QUANTIFIER -PREDICATE  IN  -> 
QUANTIFIER-PREDICATE) 

CHECK-NEC-CONO-RULE:  RUI.E304  (IN  ->  NOT  COMPARATIVE  EXTREME) 
CHECK-SUFF-COND-RULE:  RULE336  (»>  SOETECTOR!  SDETECTOR!  ->  SUBSET) 

RULE383  (»>  TRANSITIVE  TRANSITIVE  ->  TRANSITIVE) 

PROBLEM-SEPARATION-RULE : 

INTROOUCE-SPLIT-RULE:  RULE  163  (RANGE  LOC  ->  PARTITION  HANDS  PLAYERS  PILES  PLAYERS 

SET  DECK  POT  HOLE) 

RULE  164  (DIFF  OIFF  ->  UNION  DIFF  INTERSECT) 

RULE  165  (INTERSECT  SET  ->  IF  IN  SFT  NIL) 

RULE256  (PREDICATE  ->  AND  *  PREDICATE) 

RULE258  (PREDICATE  ->  AND  ->  NOT  CAUSE  ■>  NOT  UNDO) 

RULF274  (PREFIX  <■  I  ->  APPFND  PREFIX  LIST  NTH  <•  1) 

RULE276  (PREDICATE  NEXT  ->  OR  AND  NOT  CHANGE  PREDICATE  ANO 
CHANGE  PREDICATE) 

RULE338 

RULE340  (•  ->  ANO  SOROERTNG!  SORDERINGI ) 

RULE344  (UNOO  •  ->  AND  ■  8ECOME ) 

RULE356  (AT  ->  OR  NAS-OURING  CURRENT  ACTION  CAUSE  AT  BEFORE 
CURRENT  ACTION  AT) 

RULE370  (N  SET-OF  ->  -  *  SET-OF  BEFORE  CURRENT  *  SET-OF 
WAS-OURING  CURRFNT  UNDO) 

RULE385  (SET-OF  OR  ->  IF  SET-OF  OR) 
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RULE389 

PROPAGATE-SPLIT-RULE:  RULE 7  (REMOVE-l-FROM  SET-OF  ->  UNDO  AND  IN) 

RULE  10  (IN  SET-OF  ->  AND  IN) 

RULE  1 7  (SUOSET  SET  ->  AND  IN) 

RULE35  (AFFECT  AND  ->  AND  AFFECT) 

RULE59  (EXISTS  AND  -  ->  AND  IN) 

RULE64  (■  THE  ->  AND  IN) 

RULE  12 1  (SET-OF  COLLECTION  ->  UNION  IF  SET  NIL) 

RULE131  (■  THE  ->  AND  IN) 

RULE  149  (IN  SFILTER!  ->  AND  PREDICATE  IN) 

RULE  182  (IN  SET  ->  OR  *) 

RULE284  (HOMOMORPHISK  JOIN  ->  JOIN  HOMOMORPHISM) 

RULE287  (TF  ->  IF) 

RULE321  (*>  AND  ->  AND  ■>) 

RULE361  (IN  FILTER  ->  AND  IN) 

RULE371  (BEFORE  ->  BEFORE) 

RULE375  (#  SET-OF  NOT  ->  -  #  M  SET-OF) 

RULE393  (LAMBDA  FUNCTION  ->  FUNCTION  LAMBDA) 

RECURSIVE-OEFINTTION-RULE: 

CHOICE-SEQ-RULE:  RULE307  (CHOICE-SEQ-OF  EACH  ->  APPLY  APPEND  EACH  CHOICE -SEQ-OF ) 
RULE308  (CHOICE-SEQ-OF  ->  NIL) 

RULE 309  (CHOICE-SEQ-OF  CHOOSE  ->  LIST  CHOOSE) 

OEPENDENCE-RULE:  RULE203  (DEPENDENCE  J ATOM!  ->  D*  D*  DEPENDENCE  IATOM!  DEPENDENCE) 
RULE 204  (DEPENDENCE  SATOM!  ->  NIL) 

RULE205  (DEPENDENCE  INCR1-DECR2  ->  D-f  DEPENDENCE  D-  DEPENDENCE) 
RULE207  (DEPENDENCE  INCR1  SATOM!  ->  DEPENDENCE  SATOM!) 

RULE208  (DEPENDENCE  ->  INCREASING) 

RESTRUCTURE-RULE: 

TRANSFER-RULE:  RULE  13  (QUANTIFIER-PREDICATE  INJECTIVE -MAPPED-QUANT1 FIER  -> 
QUANTIFIER-PREDICATE) 

RULE  135  (EXISTENTIAI -QUANTIFIER  SET-OF  -> 

EXISTENTIAL-QUANTIFIER  AND) 

RULE  161  (QUANTIFIER  ->  QUANTIFIER  PROJECT) 

RULE187  (UNION  SET  SET  ->  UNION  SET) 

RULE219  (FORALL  SET-OF  ->  FORALL  ->) 

RULE326  (IN  ->  IN  INOICES-OF) 

RULE328  (QUANTIFIER-PREDICATE  ->  QUANTIFIER-PREDICATE  INDICES-OF) 
RULEJJO  (FORALL  INOICES-OF  IN  ->  FORALL  INDICES-OF  NOT  AFTER) 

TRANSPOSE-RULE: 

PURETRANSPOSE-RULE:  RULE5  (DIFF  SET-OF  ->  SET-OF  DIFF) 

RULE3S  (AFFECT  AND  ->  AND  AFFECT) 

RULE  108  (QUANTIFIER-PREDICATE  AND  -> 

AND  QUANTIFIER-PREDICATE  AND) 

RULE  170  (PROJECT  DIFF  ->  DIFF  PROJECT  PROJECT) 

RULE220  (=>  QUANTIFIER  ->  QUANTIFIER  •>) 

RUIE278  (CHANGE  SPROJECTION!  ->  IPROJECTION)  CHANGE) 
RULE280  (SPROJECTION!  COLLECTION  ->  COLLECTION) 

RULE283  (NEXT  SFUNCTIONAL !  ->  NEXT) 

RULE 296  (AND  NOT  NOT  ->  AND  NOT  OR) 

RULE321  (*>  AND  ->  AND  •>) 

RULE329  (PREDICATE  QUANTIFIER-PREDICATE  -> 
QUANTIFIER-PREDICATE  PREDICATE) 

RULE359  (AND  UNTIL  ->  UNTIL  AND) 

RULE360  (AND  ACHIEVE  ->  ACHIEVE  ANO) 

RULE371  (BEFORE  ->  BEFORE) 

QUASI -TRANSPOSE -RULE:  RULE58  (OURING  EACH  ->  EXISTS  DURING) 

RULE  100  (DURING  FOR-SOME  ->  EXISTS  DURING) 

RULE l 7 1  (PROJECT  SET  ->  SET) 

RULE284  (HOMOMORPHISM  JOIN  ->  JOIN  HOMOMORPHISM) 

SIMP!  IFY-RULE : 

OPPORTUNISTIC-EVALUATION-RULE:  RULE47  (■>  T  ->  T) 

RU1EI79  (REFLEXIVE  ->  T) 

RULE  184  (OR  T  ->  T) 

RULE288  (»  COLLECTION  ->  NON-NEGATIVE-INTEGER) 
RULE289  (#  NIL  ->  0) 

RULE293  (IN  ONE-OF  ->  T) 

RULE337  (SUBSET  PREFIX  ->  T) 
SIMPLIFY-7NON-CONSTANT-RULE  :  RULE  II  (AND  T  ->  AND) 

RULE  12  (•>  T  ->  T) 

RULF88  (NOT  NOT  ->  7 ) 

RU1E155  (QUANTIFIER-PREDICATE  ->  7) 

RULE  1 78  (JOIN  NIL  ->  JOIN) 
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RULE  177  (COMM-CONN  COMM-CONN  ->  COMH-CONM) 

RULE  178  (COMM-CONN  ->  7) 

RULE  185  (IF  T  ->  ?) 

RULE  188  (COMM-CONN  ->  COMM-CONN) 

RULE216  (INVERSE  ->  ?) 

RULE253  (LB: UB  ->  SET) 

RULE 255  (QUANTIFIER-PREDICATE  COLLECTION  ->  7) 
RULE281  (ONE-OF  COLLECTION  ->  7) 

RUIE310  (APPLY  APPEND  EAC.I  LIST  ->  EACH) 

RULE341  (COMM-CONN  SIDENTITY1  ->  7) 

RULE343  (COMM-CONN  SIDENT1TY!  ->  ?) 

SYSTEMATIC-EVALUATION-RULE:  RULE236  (COMPUTABLE  SCONSTANTL !  -7  SCONSTANT!) 
CONTROL-RULE:  RULE34 
RULE52 
RULE53 
RULE  190 
RULE268 
RULE269 
RULE302 
RULE312 
RULE313 
RULE 320 

RULE331  (THEN  ->  7) 

RULE334 

MAKE-ASSUMPTION-RULE:  RULE  15  (PARTITION  ->  UNION) 

RULE32 

RULE  157  (->  ->  7) 

RULE221 

RULE342  (*  SCONSTANT!  ->  T) 

RULE349  (■>  ->  T) 

USE-ASSUMPTION-RULE :  RULE346  (ANY-CONCEPT  ->  ANY-CONCEPT) 

RULE351  (ACHIEVE  -)  ACHIEVE  AND  *) 

RULE354  (AND  -  ->  AND) 

RULE364  (IN  SURROUND- VAR  I  PROJECT  ->  T) 

ALL-PUR POSE-RUl E :  RULE301  (ANY-CONCEPT  ->  FILL-IN) 

VARIABLE-RULE:  RULE  127  (SBOUND-VAR!  -)  7) 

RULE  194  (•  SUNBOUNO-VAR!  ->  T) 

RUIE27I  (■  SUNBOUSO-VARl  ->  7) 

FACT-RULE:  RULE  1  (HAS  OWNER-OF  CARO  CARD  ->  T) 

RULE2  (SUIT-OF  QS  ->  S) 

RULE61  (ACTIONS-OF  ->  PLAY-CARD) 

RULE62  (IN  QS  CARDS  ->  T) 

RULE  146  (»  PIAYER-OF  CARD  ->  •  CARO-OF  CARD) 

RULE  163  (RANGE  LOC  ->  PARTITION  HANDS  PLAYERS  PILES  PLAYERS  SET  DFCK  POT  HOLE) 
RULE  173  (IN  ME  PLAYERS  ->  T) 

RULEtSO  (AT  CARD  DECK  ->  NIL) 

RULE  197  (DOMAIN  SUIT-OF  ->  CAROS) 

RULE228  (IEGAL  CARO  ->  •  CARD  CARD-OF) 

RULE279  (CHANGE  CANTUS-1  ->  LIST  NFXT  NOTE) 

RULE285  (NEXT  CANTUS-1  ->  APPEND  CANTUS-1  LIST  NFXT  NOTE) 

RULE299  (NOT  OR  HIGHER  •  ->  LOVER) 

RULE357  (BEFORE  CURRENT  ROUNO-IN-PROGRESS  AT  CARD  PILE  ->  NIL) 

RULE363  (SUBSET  CAROS-PLAYEO  CARDS  ->  T) 

RULE365  (IN  LEADER  PLAYERS  ->  T) 

RULE37Z  (BEFORE  CURRENT  ROUND-IN-PROGRESS  IN-POT  CARD  ->  NIL) 

RULE373  (AT  CARO  HOLE  ->  NIL) 

RULE376  (0  CARDS- IN-SUIT  ->  13) 

OPERATIONALIZATION-STRATEGY: 

APPROXIMATION-RULE:  RULE  154  (COMPARATIVE  ->  SUNARY-PRED1CATE! ) 

FUNCTIONAL-DEPENOENCE -RULE :  RUl  E202  (EVAL  FORMULA  -> 

FUNCTTON-OF  DEPENDENCE  FORMULA) 

RUIE210  (FUNCTION-OF  DEPENDENCE  ->  EUNCTION-OF 
INCREASING) 


CHOICE -RULE: 

CONS TRAIN-CHOICE-RULE:  RULE156  (ACHIEVE  PREDICATE  ->  CHOOSE  SET-OF  PREDICATE) 
DESIGN-CHOICE-RULE :  RULE256  (PREDICATE  ->  AND  •  PREDICATE) 

DISJOINT-SUBSETS-RULE :  RULE  189  (PREDICATE  SSET ! -SUNKNOWN !  ->  DISJOINT  SSET! -SUNKNOWN! ) 

RUl  E 198  (DISJOINT  SUNKNOWN!  ->  PR-DISJOINT  SUNKNOWN! 

COMMON-SUPERSET  SUNKNOWN!) 

RULE200  (PR-OISJOINT  SUNKNOWN!  ->  PR-DISJOINT  SUNKNOWN!  FILTER 
SUNARY!  FILTER  SUNARY!  ) 

HISTORY-RULE:  RULF234  ( PRFOICATE  ->  WAS-DURING  CURRENT  PREDICATE) 
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NIL 


RULE356  (AT  ->  OR  MAS-OURING  CURRENT  ACTION  CAUSE  AT  BEFORE  CURRENT  ACTION 
AT) 

RULE370  [0  SET-OE  ->  -  »  SET-OE  BEFORE  CURRENT  *  SET-OF  WAS-DURING  CURRENT 
UNDO) 


HSM-RULE: 

HSM- INSTANTIATE:  (RU1E311  RULE314  RULE316  RULE317) 

HSH- PROBLEM-STATEMENT :  RULE306 
HSM-REFINE: 

HSM-CACHE:  RULE333 

HSM-FIX-UP :  RULE3I8  (LAMBOA  SET-OF 

PREDICATE  ->  LAMBOA  SET-OF  POSSIBLE  PREDICATE) 

MOVE -CONSTRAINT: 

GENERATOR-SPRECOMPUTE:  RULE 386 
PATH-7STEP-CONSTRAINT: 

PATH -ORDER ->STEP-ORO£R :  RULE338 
PATH-TEST-SSTEP-TEST:  (RULE327  RULE389) 

SIMPLIFY -BY- I NOUCTTON:  RULE390 
SOLUT ION- >PATH -CONSTRAINT: 

SOLUTION- TEST- XPATH-OROER:  RULE33S 
SOL  UTION-TEST-YPATII- TEST:  RULE  323 
SOLUT ION- TEST-SCOMPLET ION- TEST:  RULE378 
STE P- TE ST -> GENERATOR:  RULE384 
RECUCE-SEARCH-DEPTH:  RULE332 

NECESSARY-CONDITION-RULE:  RU1F319  (PREOICATE  ->  *>  PREDICATE) 

PIGEON- HOL  E -RULE :  RULE  169  (IN  ->  NOT  IN  OIFF  RANGE) 

SET-DEPl FT  ION-RULE :  RULE 6  (ACHIEVE  EMPTY  ->  UNTIL  ACHIEVE  REMOVE  -  1  -  FROM) 
SUFFICIENT-CONDITION-RULE:  RULE227  ( EVAl  PREOICATE  ->  EVAL  ->  PREDICATE) 

TEMPORAL -GOAL -RULE:  RULE258  (PREOICATE  ->  AND  ->  NOT  CAUSE  ■>  NOT  UNDO) 

RULE266  (PREDICATE  SEQUENCE  ->  FORALL  IB:UB  0  -  *  SEQUENCE  1 
PREDICATE  LAMBDA  PREFIX  SEQUENCE) 

RUIE276  (PREDICATE  NEXT  ->  OR  AND  NOT  CHANGE  PREDICATE  AND  CHANGE 
PREDICATE) 

RULE282  (ACHIEVE  ->  NEXT) 

RUL E 300  (NEXT  EXTREME  ->  EXTREME  CHANGE) 

RULE366  (ACHIEVE  PREVIOUS  ->  ACHIEVE) 


TRANSLATE-RULE : 

EL ABORATE - RUI  E :  RULE 4  (SUBSET  ->  EMPTY  OIFF) 

RULE  14  (IN  PROJECT  ->  EXISTS  •) 

RULE  1 5  (PARTITION  -)  UNION) 

RULE  124  ({EXPANDABLE!  ->  ?) 

RULE381  (INOICES-OF  -)  L8:UB  1  ») 

LATERAL -RE PHRASE -RULE:  RUL E 1 53  (COMPARATIVE  ->  COMPARATIVE) 
RULE  159  (NOT  EXISTS  ->  EMPTY  SET-OF) 
RULE218  (■  FILTER  ->  ">  IN) 

RECOGNI 7F -RUI  E .  RULE  123  ( SRFCOGNI 2ABLE  t  ->  ?) 

(EXISTS  •  ->  IN) 

(IAMBOA  ->  ?) 

(»  *  SET-OF  0  ->  NOT  EXISTS) 

(EXISTS  ■  ->  IN) 

(IF  NIL  ->  AND  NOT) 

(=  NIL  ->  NOT) 

(CAUSE  AT  ->  MOVE) 

(NOT  ->  ?) 

(UNDO  AT  ->  MOVE) 

(UNDO  NOT  ->  CAUSE) 

(OIFF  LB ;U8  LB : UB  ->  LB ; UB  -  1) 


RUI  E  162 
RULE  26  7 
RULE291 
RUI  E 292 
RULE294 
RULE352 
RULE358 
RUI  E367 
RULE368 
RULFJ77 
RULE382 
RULE387 
RULF391 
RULE J92 


(5*  »  SET-OF  l  ->  EXISTS) 
(IF  T  >  OR  NOT) 

(*<  SNON-NEGATIVE!  0  ->  • 


SNON-NEGATIVE !  0) 


<74>recordf 1  la 
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B.2.  Rule  Usage 


The  pattern  of  rule  usage  is  indicated  by  the  histogram  below.  The  most  frequently  used  rules 
were  RULE124,  which  plugs  in  the  definition  of  a  concept,  and  its  inverse,  RULE123,  which 
substitutes  the  name  of  a  concept  for  an  expression  that  matches  its  definition.  Each  rule  is  classified 
according  to  a  category  in  the  rule  taxonomy  shown  in  Appendix  B.l.  Many  of  the  41  rules  used  in 
both  the  Hearts  and  music  tasks  arc  control  rules. 

RECORD  FILE  OSK:  (0AT319  QZG)  OPENED  20-MAR-8 1  03:56:21 
NIL 

<l>p'data 


230  rules  used  in  714  steps  in  13  derivations 
Average  4  applications  of  rules  used  in  derivations  ■  3 
Histogram  of  rule  use  in  derivations: 

N  Rules  used  N  times  (♦  flags  rules  used  in  both  Hearts  and  music  domains) 


l  19: 

1 

ru  les 

<<♦ 

RUl E 1 24  ELABORATE-RULE)) 

42  : 

l 

rules 

(c 

RULE  123  RE C06N IZE-RULE)) 

20 

2 

rules 

a*- 

RULE268  CONTROL -RUl  E )  ( •■  RULE269  CONTROL -RULE ) ) 

18: 

2 

ru  les 

u- 

RUL £178  SIMPL I FY-7N0N -CONSTANT -RULE) 

(*■ 

RULE236  SYSTEMATIC-EVALUATION -RULE) ) 

15: 

l 

rules 

((*■ 

RUIEI27  VARIABLE-RULE)) 

14  : 

4 

rules 

(i- 

RULE34  CONTROL-RULE) 

(- 

RUl E  30 1  ALL-PURPOSE-RULE) 

c 

RULE 313  CONTROL-RULE) 

t* 

RUl £341  SIMPl I F Y- >NON -CONS TANT-RULE ) ) 

12 

2 

ru  l  es 

K- 

RUl F 53  CONTROL -RULE) 

c 

RULE  177  SIMPL1EY-7 NON-CONSTANT- RULE)) 

9: 

2 

rules 

u- 

RUl f 234  QUASI -TRANSPOSE -RUl E  PROPAGATE -SPl I T-RULE ) 

(* 

RULCJJ6  USl-ASSUMPTlOH-RUll}} 

8: 

2 

rules 

((RUl  Ell  SIMPL l EY- >NON -CONS TANT-RULF. ) 

<♦ 

RULE343  SIMPL I FY-^NON -CONSTANT -RUl E ) ) 

7; 

2 

rules 

((♦ 

RUl  E  1 94  VARIABLE-RULE)  (  +  RUl  €2  7  1  VAR  I  ABl  E -RULE  ) ) 

6: 

2 

rules 

( (  RULF43  MATCH  RULE)  ( <■  RULE  l  79  OPPORTUNISTIC-EVALUATION 

5. 

7 

ru  1  es 

((- 

RUl  f 12  SIMPl IFY- > NON -CONSTANT -RULE ) 

( RIM  E 35  PURE -TRANSPOSE -RULE  PROPAGATE -SPL  I T -RUl. E  ) 
(RUIE176  SIMPl  IFY->NON-CONSTANT-RULE) 

RULEJ12  CONTROL-RULE) 

(*  RUL E 323  SOLUTION -TEST- >PATH-TEST) 

(RULE 320  PURE -TRANSPOSE -RULE) 

(♦  RUl F 334  CONTROL-RULE)) 

4  6  rules  ( (RULE?  FACT-RUI F ) 

(RULE  10  PROPAGATE -$P1  IT -RUl  E) 

(RULF57  TNTFRSFCT ION- SEARCH -RULE) 

(♦  RUL F 153  LATERAL -RE PHRASE- RULE ) 

(RULE  173  FACT-RULE) 

(RULE 292  REC0GNI7F.-RULE  ) ) 

3:  15  rules  ( ( RULE30  MATCH-RULE) 

(RULE32  MAKE -ASSUMPTION-RULE) 

(RULE64  PROPAGATE -SPL IT -RUl E ) 

(RULE83  SIMPL I FY->N0N- CONSTANT -RULE ) 

(RULE9L  MATCH-RULE) 

(RUl E 135  TRANSFER-RUtf ) 

(RUl E  151  RFOUCF -SUE F-CONO -RULE) 

( RUL  E  l  72  MATCH-RULE) 

(RULF 184  OPPORTUNISTIC -EVALUATION-RULE ) 

{♦■  RULE  192  MATCH-RULE) 

(RUIE267  RECOGNIZE -RULE ) 

(RULE291  RECOGNI ZE -RUl E ) 

(♦  RULF327  PATH-TEST->STFP-TEST) 

(♦•  RULE33I  CONTROL -RULE) 

(RUl F 358  RECOGNIZE -RULE  ACTION-RULE)) 

2:  44  rules  ((RUL Ft  FACT  RULE) 

{ RUL  F 6  SFT -OFPLE  TIOM-RUl E ) 

(RULF7  PROPAGATE -SPl IT-RULE) 


m 
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(RULE  4 7  OPPORTUNISTIC  E VALUATION- RULE) 

(RUIE58  QUASI -TRANSPOSE  RUI  E ) 

(RULE 59  PROPAGATE  SPl I T -RUL E ) 

(RULE109  EXAMPt E-RULE) 

(RULE  12 1  PROPAGATE -SPL I T - RUL  E  ) 

(♦  RUL F 1 3 1  PROPAGATE-SPLIT-RULE) 

(RULE M9  PROPAGATE -SPLIT-RULE) 

(RULE  154  APPROXIMATION-RULE ) 

(RULE  155  SIMPLIFY->N0N- CONSTANT -RULE) 

(RUI E 162  RECOGNIZE-RULE) 

(♦  RUL E 182  PROPAGATE-SPLIT-RULE) 

(♦  RUL E 1 85  SIMPt  IFY->NON  CONSTANT -RULE ) 

(♦  RULE  188  SIMPL IFY->NON-CONSTAKT-RULE) 

(RULE204  OEPENOENCE-RULf ) 

(RULE205  DEPENDENCE-RULE) 

(RUIE279  FACT-RULE) 

(RULE2S1  SIMPL I FY - >NON' CONSTANT -RULE ) 

(RUIE28J  PURE-TRANSPOSE-RULE) 

( RUI E 287  PROPAGATE-SPLIT-RULE) 

(RULE288  OPPORTUNISTIC -EVALUATION- RULE) 

(RULE 290  HFURIST1C- EQUIVALENCE -PRESERVING -RULE) 
(RULE302  CONTROL-RULE) 

(♦  RUL  F  306  DETECT- APPLICABILITY  HSM- INSTANTIATE) 

(  +  RULE307  CHOICE-SEQ-RULE) 

(•*■  RULE309  CHOICE-SEQ-RULE) 

(♦  RUIE310  SIMPL I FY- > NON- CONSTANT -RULE ) 

(♦  RULE  311  HSM- INSTANT  I  ATE ) 

(♦  RUIF314  HSM- I NSTANT I  ATE ) 

(♦  RULE315  FUNCTIONAL-RECURRENCE-RULE) 

(♦  RUI 6317  HSM- INSTANTIATE ) 

(RULE 3 19  NECESSARY -CONDITION-RULE) 

(KUIE320  CONTROL-RULE) 

(♦  RUIE323  TRANSFER-RULE) 

<  +  RULf 340  INTRODUCE -SPL  TT-RULE ) 

(RULE354  USE -  ASSUMPTION  RULE  REOUCE-  ''NEC  -COND-RULE  ) 
( RUI f 36 1  PROPAGATE -SPL I T -RUI  E) 

(RULE368  RECOGNIZE-RULE  ACTION-RULE) 

( RULE  37  l  PURE-TRANSPOSE-RULE  PROPAGATE-SPLIT-RULE) 
(RULE379  MATCH-RULE) 

(RULE383  CHECK-SUFF-COND-RULE) 

( RUI  E 303  PROPAGATE-SPLIT-RULE  FUNCT IONAL I 7E -RULE ) ) 

l.  130  rules 

0  7  rules  | ( RUI E  156  CONS  TRAIN-CHOICE -RULE  ) 

(RULF211  FUNCTIONAL -RFCURRFNCE-RULE ) 

(RULE258  INTROOUCE-SPl IT-RULE  TFMPORAL- GOAL-RULE ) 

( RUL  F  2  78  PURE-TRANSPOSE-RULE) 

(RULE280  PURE-TRANSPOSE -RUI E  ) 

(RUIE235  FACT-RULE) 

(RULE 303  SPECIAL -CASE -REDUCTION -RULE)) 

NIL 

<2>recordf  i  le 

RECORD  F  T  LE  DSK :  (DAT3 19  .  QZG)  CLOSED  20-MAR-81  03:57:09 
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§13.  Transformation  Rules 


B.3.  Interpretation  of  Rules  in  foo 

This  section  uses  a  precise  rule  notation  to  give  a  sense  of  concreteness  and  to  illustrate  how  the 
rule  interpreter  works.  Appendix  B.4  lists  all  the  rules  in  this  notation. 

To  illustrate,  consider  the  following  somewhat  informally  stated  rule: 

RULE284:  (f ...  ( +  ^  ...  en) ...)  ->  (  +  ’  (f ...  ex ...) ...  (f...  en  ...)) 

where  +  is  an  addition-like  operator  over  the  domain  of  f,  +’  is  the  corresponding  operator 
over  the  range  of  f,  and  (lambda  (x)  (f ...  x  ...))  is  a  homomorphism  with  respect  to  +  and  +' 

A  transformation  rule  in  FOO  has  the  following  form  (braces  indicate  optional  components): 

RULEnnn:  {**  <componen t>)  •  <lhs>  ->  <rhs>  {IF  <test>} 

To  apply  RULEnnn,  the  <1hs>  pattern  is  matched  against  an  expression.  The  <component> 
pattern,  if  present  is  matched  against  a  selected  argument  of  the  expression.  If  the  <test>  is 
satisfied,  the  <rhs>  is  instantiated  and  substituted  for  the  expression. 

Thus  RULE284  is  stated  in  a  precise,  machine-oriented  notation  as 

RULE284 :  *•  (?S  :  (JOIN  &  ?L) ) 

•  ( ?E  :  ( (?F  :  HOMOMORPHISM)  &  ?M))) 

->  ((!  SAOO-OF  ?F) 

&  ( !  SOISTR I  BUTE  ?X  ?L  (!!  !  SSUBST  ?X  ?S  ?E))) 

The  symbol  JOIN  corresponds  to  the  addition-like  operator  +,  and  ( !  SADD-OF  ? F )  corresponds 
to  +’. 

"Machine-oriented  notation"  is  not  the  same  as  “internal  representation."  A  rule  is  represented 
internally  in  FOO  as  a  LISP  atom  with  properties  corresponding  to  various  rule  components.  The 
precise  notation  shown  above  is  mechanically  generated  from  this  internal  representation,  with 
punctuation  added  for  readability. 

The  notation  uses  the  following  symbols: 

*  precedes  pattern  to  be  matched  against  the  expression  e  to  which  tire  rule  is  applied 
••  precedes  pattern  to  be  matched  against  a  specified  component  ofc 
~>  precedes  pattern  to  be  substituted  for  e  in  the  current  overall  expression 
IF  precedes  condition  to  be  satisfied  in  order  for  rule  to  be  applied 
7  prefix  denotes  a  variable,  e.g.,  ?S 
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:  is  a  binding  operator,  e.g.,  ( ?F  :  HOMOMORPHISM) 

$  prefix  indicates  a  procedure,  e.g.,  SSUBST 
&  is  a  concatenation  operator,  e.g.,  ( JOIN  &  ?L) 

!  is  an  evaluation  operator,  e.g.,  ( !  SAOD-OF  ?F) 

1 !  is  a  quoting  (evaluation-delaying)  operator,  e.g..  (! !  !  SSUBST  ?x  ?S  ?E) 

Q*V  generates  unique  variable  names,  e.g.,  ( !  Q*V  ?X) 

FOO  decides  if  a  rule  can  be  applied  to  an  expression  by  matching  the  left-hand  side  of  the  rule 
against  the  expression.  The  process  of  matching  a  rule  pattern  to  an  expression  is  performed  top- 
down  without  backtracking,  andean  be  described  recursively: 

1.  Match  unbound  (var>  to  e  by  binding  <var>  to  e. 

2.  Match  bound  <var>  to  e  by  matching  its  binding  to  c. 

3.  Match  literal  c  to  c  by  testing  if  e  is-a  c. 

4.  Match  (<pat^>  :  <pat_,»  to  e  by  matching  <pat1>  to  e  and  <pat2>  to  e. 

5.  Match  (<patj>  &  <pat2>)  to  (f  e^ ...  cr)  by  matching  <patx>  to  f  and  <pat,>  to  (e1 ...  c  ). 

6.  Match  (<pat1>  ...  <pat  >)  to  (ex ...  en)  by  matching  <patx>  to  ev . <patn>  to  e  . 

The  left-hand  side  of  RULE284  is  a  two-part  pattern;  one  part,  prefixed  by  a  single  asterisk,  is 

matched  against  an  expression,  and  the  other,  prefixed  by  a  double  asterisk,  is  matched  against  an 

argument  of  that  expression.  This  is  illustrated  by  the  transformation 

(DURING  (SCENARIO  (EACH  PI  (PLAYERS)  ( PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME)) 

6:4  ---  [DISTRIBUTE  by  RULE284 ]  ---> 

(OR  [DURING  (EACH  Pt  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-POINTS  ME)] 

[DURING  (TAKE-TRICK  ( TR ICK-WI NNER ) )  (TAKE-POINTS  ME)]) 


The  pattern  ( ?E  :  ((?F  :  HOMOMORPHISM)  &  ?M) ))  is  matched  against  the  expression 

(DURING  (SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME)) 

This  is  done  by  searching  through  an  is-a  hierarchy  (§ l.J.2.1)  to  find  a  path  from  DURING  to 
HOMOMORPHISM.  The  variable  ?E  is  bound  to  the  whole  expression,  ?M  is  bound  to  the  list  comprising 
its  two  arguments,  and  ?F  is  bound  to  the  function  DURING. 

Similarly,  the  subpart  pattern  (?S  :  (JOIN  &  ?L) )  is  matched  against  the  sub-expression 
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(SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

This  is  done  by  by  finding  a  path  from  SCENARIO  to  JOIN.  The  variable  ?S  is  bound  to  the  sub¬ 
expression  and  ? L  is  bound  to  the  list  comprising  its  two  arguments.  Note  that  the  user  specifies 
which  sub-expression  to  match  the  subpart  pattern  against. 

The  matching  process  has  two  purposes.  One  is  to  verify  the  appropriateness  of  applying  the  rule. 
If  a  rule  does  not  match  an  expression,  FOO  will  not  attempt  to  apply  it.  For  example,  RULE284 
produces  a  valid  transformation  provided  the  homomorphism  condition  is  satisfied,  POO  would 
refuse  to  apply  RULE284  at  step  6:4  if  either  of  the  relations  DURING  is-a  HOMOMORPHISM  and 
SCENARIO  is-a  JOIN  were  not  satisfied. 

The  other  purpose  of  matching  is  to  bind  variables  used  in  the  pattern  on  the  right-hand  side  of  the 
rule.  This  pattern  is  instantiated  by  filling  in  variable  bindings  and  executing  any  embedded 
procedures.  The  instantiation  process  is  illustrated  below  for  the  right-hand  side  of  RULE284: 

((!  $ AOD-OF  ?F )  &  ( !  SDISTRIBUTE  ?X  ?L  (!!  !  SSUBST  ?X  ?S  ?£))) 

First  the  sub-pattern  (!  SADD-OF  ?F).  corresponding  to  the  addition-like  operator  +’  in  the 
informal  statement  ofRULE284,  is  evaluated  by  filling  in  DURING  as  the  binding  for  ?F,  and  applying 
the  procedure  SADD-OF  to  DURING.  FOO  finds  the  stored  relation  ADD  of  DURING  is  OR  in  its  semantic 
network  of  objcct-attribute-value  triples  (§1.3.2),  and  returns  the  function  OR.  Thus  foe  expression  to 
be  substituted  for  the  original  expression  will  be  in  the  form  of  a  disjunction.  Note  that  the  symbol  1 
in  ( !  $ADD-0F  ?F )  indicates  procedure  application;  FOO  would  instantiate  the  pattern 
(SADD-OF  ?F)  as  the  literal  expression  (SADO-OF  DURING). 

The  procedure  SDISTRIBUTE  is  a  mapping  quantifier  similar  to  MAPCAR  in  LISP.  The  sub- 
pattern  ( !  SOISTRIBUTE  ?X  ?L  (!!  !  SSUBST  ?X  ?S  7E ))  is  evaluated  by  binding  the  variable 
?X  to  successive  clemenLs  of  the  list  bound  to  ?L  and  instantiating  (! !  !  SSUBST  ?X  ?s  ?E)inthe 
context  of  each  such  binding.  This  in  turn  is  done  by  using  the  procedure  SSUBST  to  substitute  the 
expression  bound  to  ?x  for  the  expression  bound  to  ?S  throughout  the  expression  bound  to  ?E.  The 
symbol  ! !  keeps  FOO  from  trying  to  fill  in  tire  binding  of  ?x  prematurely,  Le..  before  the  procedure 
SDISTRIBUTE  is  applied.  The  result  returned  by  SDISTRIBUTE  is  the  list  of  expressions  produced  by 
instantiating  ( !!  !  SSUBST  ?x  ?S  7E )  for  each  ?X  in  ?L. 

The  ampersand  in  die  right-hand  side  of  RULE284  acts  as  a  concatenation  operator;  it  tells  FOO  to 
append  diis  list  to  the  function  OR  found  earlier.  This  produces  die  disjunction 
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(OR  [DURING 
[DURING 


(EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE  POINTS  ME)] 

(TAKE-TRICK  (TRICK-WINNER))  (TAKE-POINTS  ME)]) 


This  is  substituted  at  step  6 :  4  for  the  expression  bound  to  the  left-hand  side  of  RULE284. 
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B.4.  List  of  Rules 


foo’s  rules  are  listed  below  in  the  notation  explained  in  Appendix  B.3. 


RECORD  FILE  OSX:  (RUL319  .  QZG)  OPENEO  20-MAR-81  18:32:13 
NIL 

<89>p-ru1es  nil 


230  rules  in  use  as  of  "20-MAR-81  18:32: t3" 

(RULE  1  (FACT-RULE  USED  2  TIRES)  •  (HAS  (0MNER-0F  ?C)  ?C)  -)  T) 

Used  in.  ((0ERIV3  :  22  70)) 

(RULE 2  (FACT-RULE  USED  4  TIRES)  •  (SUIT-OF  QS)  ->  S) 

Used  in:  ( (DERIV3  :  25  30  72)  (0ERIV5  ;  45)) 

(RUIE4  (ELAOORATE-RULE  USED  1  TIMES) 

•  (SUBSET  ?X  7Y) 

->  (EMPTY  (OIFF  IX  ?Y ) ) ) 

Used  in:  ((OERIV3  :  37)) 

(RUIE5  (PURE-TRAMSPOSE-RULE  USED  l  TIMES) 

•  (OIFF  (SET-Of  ?X  ?S1  ?P)  ?S2 ) 

->  (SET-OF  ?X  (DIFF  ?Sl  ?S2 )  ?P) 

(VOTE  IDENTITY  (OIFF  (INTERSECT  SI  P)  S2) 

*  (INTERSECT  SI  P  (COMPLEMENT  S2 ) ) 

•  (INTERSECT  (OIFF  SI  S2 )  P ) > ) 

Used  in:  ( (OERIV3  :  40)) 

(RULE6  ( SI  T -DEPLETION -RULE  USED  2  TIMES) 

•  (ACHIEVE  (EMPTY  ?S) ) 

-> 

(UNTIL  (!  JFIIL-IN  "Supergoal  of  emptying  set") 

(ACHIEVE  (REMOVE- 1  FROM  ?S))) 

(FILL-IN  SIMULATES  EFFECT  OF  RETRIEVING  SUPERGOAl  FROM  STORED  EXPLANATION 
OF  HEURISTIC)) 

Used  in:  ((OERIV3  :  38)  (0ERIV8  :  3)) 

( RULE 7  (PROPAGATE-SPUT-RULE  USED  2  TIMES) 

•  (REMOVE- t-FROM  (SET-OF  ?X  ?S  ?P)) 

->  (UNDO  (ANO  [IN  ?X  ?S]  ?P))) 

Used  in:  ( (DFRIV3  :  41 )  (0ERIV8  :  4)) 

(RULE10  (PROPAGATE-SPUT-RULE  USEO  4  TIMES) 

•  (IN  ?C  (SET  OF  ?X  ?S  IP)) 

-)  (ANO  [IN  ?C  IS]  [ !  SSUBST  ?C  ?X  ?P])) 

Used  in:  ((OERIV2  :  91)  (DERIV3  .  17)  (0ERIV5  :  16)  (OERIV8  :  7)) 

(RULEU  (SIMPLIFY-)NON-CONSTANT-RULE  USEO  8  TIMES) 

••  (?P  :  T) 

•  (?Q  :  (ANO  &  ?L ) ) 

->  (!  SREMOVE  ?P  ?Q) ) 

Used  in:  ((OER1V2  :  33  -  34  ,  53  60  86) 

(OERIV3  :  23  29  82)) 

(RULE  12  (SIMPlIFY->NON-CONSTANT-RUlE  USEO  5  TIMES) 

•  (*>  T  ?P) 

->  IP) 

Used  in:  ((OERIV3  :  86)  (0ERlVt3  :  26  50  70  102)) 

(RULE  13  (TRANSFER-RULE  USEO  1  TIMES) 

((IQ  :  QUANTIFIER  PREDICATE) 

IX  ( ( ?M  :  INJECTIVE  MAPPED  QUANTIFIER) 

?Y  IS  IE) 

?P) 

->  (IQ  7Y  IS  (I  SSUBST  IE  IX  IP))) 
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Used  in:  ((0ERIV13  :  30)) 

(RULE14  (ELABORATE -RUE E  USEO  L  TIMES) 

•  ( EM  ?E  (PROJECT  ?F  ?S)) 

-> 

(EXISTS  (?X  :  ( !  Q*V  ( !  SF  ILL  -  IN  "variable  name"))) 

?S  (■  ?E  (?F  ?X ) ) ) ) 

Used  in:  ((0ERIV4  .  45)) 

(RULE  15  (ELABORATE -RULE  MAKE - ASSUMPT I  ON -RULE  USEO  1  TIMES) 

•  (PARTITION  4  ?L) 

->  (!  SASSUMING  (DISJOINT  4  ?L)  T  (UNION  &  ?L ) ) ) 

Used  in:  ( (DERIV4  :  10)) 

(RULE  1 7  (PROPAGATE-SPIIT-RUIE  USED  1  TIMES) 

•  (SUBSET  (SET  4  ?L)  ?S) 

->  (AND  &  [!  SD1STRI8UTE  ?XX  ?L  (IN  .'XX  ?S)])) 

Used  in:  ((0ERIV3  :  14)) 

(RULE  19  (SPECIAL -CASE -REDUCT ION -RULE  USED  1  TIMES) 

•  ( ?D  :  (DIFF  (JOIN  8  ?L)  ?S ) ) 

->  ('  STRV  '0  (DISJOINT  4  'L )  (JOIN  4  (I  SREMOVE  ?SS  ?L))) 

IF 

(AND  [■  SIN!  (!!  7SS  :  ?S  )  ?L]  [!  STRYABLE!  To  (DISJOINT  4  ?L)]) 

--  (?SS  MACK  IS  TO  MAKE  SREMOVF  wGRX  AS  DESIRED) 

((DIFF  (JOIN  ?S  4  ?L)  ?S)  ->  (JOIN  4  L ) ) > 

Used  in:  ((DERIV4  16)) 

(RULE30  (PARTIAL -MATCH-RULE  USED  3  TIMES) 

•  ( ?E  :  ( ( ?R  :  TRANSITIVE) 

(TF  ?S1) 

(?F  (?S2  :  SSET I ) ) ) ) 

->  ( !  SSUFFICE  ?E  (SUBSET  ?S l  ?S2 ) ) 

--  (ASSUMING  (SUBSET  ?S1  ?S2)  *>  <?R  (?F  ?S1)  (?F  ?S2)))) 

Used  in:  ( (DERIV13  :  23  46  96)) 

(RULE32  (MAKE-ASSUMPTION-RULE  USED  3  TIMES) 

•  (?G  :  (SHOW  ?Q)) 

->  ( !  SHARK  (ASSUMING  7Q)  (!  SRETURN  ?8  ?E ) ) 

TF  (STRIEO!  ?8  ?P  7F  ?G) 

—  (OPTIMISTIC  CASE:  ASSUME  ?Q  IS  TRUE)) 

Used  in.  ( (DERI V2  :  64  67)  (DERIV9  :  37)) 

(RULE34  (C0NTROL-R"LE  USED  14  TIMES) 

•  ( ?G  :  (SHOW  T)) 

-7  ( !  SHARK  (FACT  ?B  ->  ?E)  (I  SRETURN  ?B  ?E ) ) 

IF  (STRIED!  ?B  ?P  ?E  7G) 

(TEST  SHOULD  INCORPORATE  OTHER  CONSTRAINTS  IN  ORIGINAL  RULE  AND  DEPEND 
ON  STATE  OEPFNDENCIES  AND  LIMITATIONS  OF  RESULT  DERIVATION) 
(RECORD  SPECIAL  CASE  RULE  TO  ->  ?E ) ) 

Used  in:  ((DERIVE  :  85  100) 

(0ERIV3  :  59) 

(DERIV4  :  18) 

(0ERIV5  :  49) 

(DERIV6  .  19  49) 

(DERIV9  :  14) 

(OERIVIO  :  t2) 

(DERIVU  :  5) 

(DERIV12  :  13) 

(DERI V13  :  39  76) 

(0ERIV14  :  57)) 

(RULE35  (PURE -TRANSPOSE -RULE  PROPAGATE-SPUT-RULE  USED  5  TIMES) 

•  (AFFECT  (AND  4  ?l)) 

->  (ANO  [AFFECT  (?P  :  (!  SSELECT  ?L))]  4  [I  SREMOVE  ?P  ?L]) 

—  (SEE  RULE280) 

(SUFFICIENT  CONDITION  —  NECESSARY  IF  ?P  IS  ONLY  CHANGEABLE  „NJUNCT)) 
Used  in:  ((0ERIV3  .  42  44)  (0ERIV8  :  5  8)  (0ERIVI2  :  7)) 

(RULE43  ( PARTIAL -MATCH -RULE  USEO  6  TIMES) 

•  ( ( ?R  :  REFLEXIVE) 
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( (  ?F  :  (-  QUAMTIF IER ) )  It  ?L) 

(?F  8  IM) J 

->  (AND  i  [ !  SOISTRIBUTEL  (7X1  7YI)  (?L  ?N)  (•  ?X  I  7YI)]) 

If  (SEQUAl -LENGTH!  ?l  ?M) 

(SUFFICIENT  CONDITION  --  NECESSARY  IF  (R  (F  X)  (F  Y)) 

->  X  •  Y)) 

Used  In:  ((0ERIV3  :  52  55) 

(0ERIV5  :  12) 

(DERIV6  :  11) 

(0ERIV9  :  33) 

(DERIV11  :  11)) 

(RULE47  (OPPORTUNISTIC-EVALUATION-RULE  USED  2  TIMES) 

•  (■>  IP  T) 

->  T) 

Used  In:  ( (DERIV3  :  28  33)) 

(RULE52  (CONTROL-RULE  USED  1  TIMES) 

•  ( ?G  :  (SHOW  NIL)) 

->  ( !  SRETURN  ?P  NIL) 

IF  ( (CHECKED !  ?P  IQ  ?G) ) 

Used  in:  ((0ERIV14  :  76)) 

(RULE53  (CONTROL-RULE  USED  12  TIMES) 

•  (?G  :  (SHOW  T)) 

->  ( !  SRETURN  ?P  T) 

IF  (SSUFFICFO!  ?P  ?0  ?G) ) 

Used  in:  ( (DERIV2  :  52  99) 

(DERIV3  :  75) 

(0ERIV6  .  58) 

(OERIVU  :  4) 

(DERIV13  :  25  48  -  49  :  69  99  101)) 

(RULE57  (INTERSECTION-SEARCH-RULE  USED  4  TIMES) 

•  (DURING  ?X  ?Y ) 

->  NIL  IF  { SOIS  JOINT !  ('.  SPARTS<EVENT  ?X)  (!  $GENL<£VENT  ?Y ) ) ) 
Used  in:  ((0ERIV5  :  8)  (0ERIV6  :  5)  (0ERIV10  :  10)  (OERIVU  :  II)) 

(RULE58  (QUASI-TRANSPOSE-RULE  USED  2  TIMES) 

•  (DURING  (EACH  ?X  ?S  ?F)  ?E) 

->  (EXISTS  ?X  ?S  (DURING  ?F  ?E ) ) ) 

Used  in:  ((OERIV5  :  11)  (OFRIV6  :  9)) 

(RULF59  ( PROPAGATE -SP1  IT-RULE  USED  2  TIMES) 

•  (EXISTS  ?X  IS  (IP  :  (AND  &  ?L ) ) ) 

->  (AND  [IN  ?C  ?S]  &  [ !  SSUQST  ?C  IX  (!  SREMOVF  IQ  ?L ) ] ) 

IF 

(OR  [ !  SIN!  (!!  IQ  :  (■  IX  ?C ) )  7L] 

[ !  SIN!  (!!  IQ  :  (•  IC  IX))  IL])) 

Used  in:  ((0ERIV5  :  13)  (OERrV6  :  12)) 

(RULF61  (FACT-RULE  USED  l  TIMES) 

•  (ACTIONS-OF  IP) 

->  (PLAY-CARD  IP) 

IF  (TRICK-IN-PROGRESS)) 

Used  in:  ((DERIV3  :  5)) 

(RULE62  (FACT-RULE  USFO  t  TIMES)  ♦  (IN  QS  (CAROS))  -)  T) 

Used  in:  ((0ERIV3  :  18)) 

(RULE64  ( PROPAGATE -SPL I T -RULE  USED  3  TIMES) 

•  (*  IC  (THE  IX  IS  IP)) 

->  (ANO  [IN  IC  IS]  [I  SSUDST  IC  IX  IP])) 

Used  in:  ((0ERIV2  :  77)  (DERIV5  :  19)  (DERIV5  :  32)) 

(RULE84  (f XAMPLE-RUIF  USED  t  TIMES) 

•  (IE  :  (FINO-ELT  IS)) 

->  ( !  STRY  IE  (IN  7C  IS)  IC) 

IF 

(SEXISTS!  (!!  IN  (IC  :  SCONSTANT!)  IL) 

(!  SPREHtSES-OF  IE) 
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(I !  STRYA8LE !  ?E  (IN  ?C  ?S ) } ) ) 

Used  in:  ((0ERIV5  :  39)) 

(RULES8  (S IMPL I FY-> NON -CONSTANT -RULE  USED  3  TINES) 

•  (NOT  (NOT  7P)) 

->  ?P) 

Used  in:  ((OERIV2  :  43)  (OERIV5  :  38)  (OERIV6  :  41)) 

(RULE91  (PARTIAL -MATCH-RULE  USED  3  TIMES) 

•  (?E  :  ( ( ?R  :  REFLEXIVE)  (?F  i  ?L)  (?F  &  ?M))) 

-> 

( !  JSUFF1CE  ?E 

(AND  &  [!  SDISTRI8UTEL  (?XI  ?YI)  (?L  ?M)  (•  ?XI  7YI)])) 

IF  (SEQUAL -LENGTH !  ?L  ?M) ) 

Used  in:  ((OERIV2  :  48  62)  (0ERIV6  :  54)) 

(RULE  100  (QUASI-TRANSPOSE-RUl E  USED  l  TIMES) 

•  (DURING  ?T  (FORSOME  ?X  ?S  ?E ) ) 

->  (EXISTS  ’X  ?S  (DURING  ?T  ?E))) 

Used  in:  ( (DERIV6  :  10)) 

(RULE  103  (PURE-TRANSPOSE-RULF  USED  I  TIMES) 

•  ( ?E  :  ((?0  :  QUANTIFIER  PREDICATE) 

?X  ?S  (AND  &  ?L ) ) ) 

->  (AND  ?P  ['Q  ?X  ?S  (AND  &  [!  SREMOVE  ?P  7L])]) 

IF  (SEXISTS!  ?P  ?L  (!!  SINCE PENOEN T -OF  ?P  ?X ) ) ) 

Used  in:  ( (DERIV6  :  13)) 

(RULE  109  (EXAMPLE-RULE  USED  2  TIMES) 

•  (NOT  (AND  &  ?L)) 

-> 

(«>  (ANO  4  [ !  SREMOVE  ?£  ?L]) 

(NOT  (!  SSUBST  (FINO-EIT  ?S)  ?X  ?Q ) ) ) 

IF  (SIN!  (!!  ?E  :  (FORALL  ?X  ?S  ?Q ) )  ?L ) ) 

Used  In:  ( ( OER IV5  :  35)  (DERIV6  :  40)) 

(RULE  121  (PROPAGATF-SPLIT-RULE  USED  2  TIMES) 

•  (SET-OF  ?X  (COLLECTION  t  ?L)  ?P) 

-> 

(UNION  &  (!  SDISTRI8UTE  7Y  7L  (!!  IF  (!  SSUBST  7Y  ?X  ?P) 

(SET  TY) 

NIC)))) 

Used  in:  ((0ERIVI4  :  20  64)) 

(RULE  123  (RECOGNIZE-RULF  USED  42  TIMES) 

•  ?E  ->  (!  SRFCOGNIZE  ?E  (!  SSELECT  ?L)) 

IF 

(SNON-EMPTY!  ( ?L  : 

(!  SSET-OF  (!!  ?F) 

(!  $FNS<  E  ?E ) 

(It  !  SRECOGNIZABLE !  ?E  ?F ) ) ) ) ) 

Used  in:  ( (DFRIV2  :  17) 

(DERIV3  :  2  -  3  ;  50  87  93  -  94  ;  96  -  97) 

(DERIV4  :  14  34  -  37  ;  40  -  42  :  46  62  -  54) 

(DERIV5  :  52  -  53) 

(DERIV6  :  21  -  22) 

(OER1V8  :  11  14) 

(DERIV9  :  12  38  -  39  ;  41  -  43) 

(DERIV10  :  9  30) 

(DFRIVtl  :  18) 

(OERIV12  :  10) 

(OERIV13  :  14) 

(OERIVt4  :  16  17  43  79)) 

(RULE124  (ELABORATE-RULE  USED  119  TIMES) 

•  (?E  :  SEXPANOAOLE! ) 

->  ( !  SEXPAND-DEF  ?E ) ) 

Used  in:  ( (DERIV2  :  l  -  2  ;  5  11  24  27  29  41  -  42  ;  44  75  -  76  ;  78  90  103) 

(0ERIV3  :  1  4  6  16  20  -  21  ;  24  39  43  47  -  48  ;  5!  65  -  66  ;  68  71  83 

90  92) 

(DFRIV4  :  l  -  4  ;  1122  44) 

(DERIV5  :  2  6  10  14  16  -  18  ,  20  22  26  -  27  ;  29  -  30  ;  40  44) 
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(DERIV8  :  t  -  3  ;  7  -  8  ;  15  24  -  25  ;  29  -  3 1  ;  34  46  52  -  53 ) 
(0ERIV7  .1-2) 

(DERIV8  :  1  6  9) 

(DERIV9  :  1  3  -  4  ;  8  23  -  24  ;  29  31  40  49) 

(OERIVIO  ;  1  ~  3  ;  S  7  26  28) 

(OERIVtt  :  7) 

(DERIV12  :  2  4  8) 

(DER1V13  :  3  5  It  -  12  ;  16  29  60  -  61  ;  84  94  -  95  ;  112) 
(0ERIV14  :  10  -  11  ;  19  29  32  41  53  63  70  85)) 

(RULE  127  (VARIABLE-RULE  USED  15  TIMES) 

•  (?X  :  JBOUNO-VAR1) 

->  ( I  JBINOINGCVAR  ?X ) ) 

Used  in:  ( (DERIV2  :  36  38  55  88) 

(DERIV3  :  60-61) 

(0ERIV6  :  51  60) 

(DERIV9  :  18  20) 

(OERIV1 1  :  6  15  -  16) 

(0ER7V13  :  41  78)) 

(RULE  131  (PROPAGATE -SPLIT-RULE  USED  2  TIMES) 

•  (>  (THE  7X  ?S  ?P)  ?C) 

-)  (AND  [IN  ?C  7S]  [!  JSUBST  ?C  7X  ?P])) 

Used  in:  ( (DERIV6  •  26)  (DERIV13  :  62)) 

(RULE135  (TRANSFER-RULE  USED  3  TIMES) 

•  ( ( ?Q  :  EXISTENTIAL  QUANTIFIER) 

?X  (SET-OF  ?Y  ?S  ?P) 

?R) 

->  (?Q  ?X  ?S  (AND  [ !  JSUBST  ?X  ?Y  ?P]  ?R ) ) 

(WORKS  FOR  ?Q  IN  (SET-OF  THE  EXISTS) 

BUT  NOT  (FORALL  FOR-SOME  EACH  DISTRIBUTE  CHOOSE))) 

Used  in:  ((0ERIV2  :  45)  (DER1V3  :  67)  (OERIV12  :  5)) 

(RULEI42  (EXAMPLE-RULE  USEO  l  TIMES) 

••  ( ?E  :  (FIND-ELT  ?S ) ) 

•  (?P  :  (PREDICATE  &  7ETC ) ) 

-> 

(!  JSUFFICE  ?P 

(AND  [IN  (?C  :  ( !  g*v  ( 1  SFILL-IN  "instance  name")))  7S] 

[ !  JSUBST  ?C  7E  ?P]))) 

Used  in:  ( (DERIV6  :  44)) 

( RULE  146  (FACT-RULE  USEO  l  TIMES) 

•  (*  (PLAYER-OF  ?C)  ?P) 

->  (■  (CARO-UF  ,'P)  ?C ) ) 

Used  in:  ((OERIV5  :  15)) 

(RULE  149  (PROPAGATE-SPLIT-RULE  USEO  2  TIMES) 

•  (IN  ?C  ( ( ?A  :  JFILTFR!)  ?S ) ) 

->  (AND  [|  JPREDYADU  ?A  ?C]  (IN  ?C  ?S])) 

Used  in:  ( (DERIV6  :  33  45)) 

(RUI.E151  (REOUCE-SUFF-COND-RULE  USED  3  TIMES) 

•  (?G  :  (SHOW  ?X)) 

->  ( !  JMARK  (FAILED  ?Q  7G)  (!  JRETURN  ?P  ?X)) 

IF  (JSUFFICEO!  ?P  ?Q  ?G) 

--  (RETURN  REDUCED  RESULT  —  USEFUL  AS  GOAL)) 

Used  in:  (((1ERIV2  :  37  72)  (OERIV6  :  61)) 

(RUIF153  il  ATFRAL-RFPHRASE-RULE  USED  4  TIMES) 

•  ( ( ?R  :  COMPARATIVE)  7E1  7E2) 

->  ((!  JOPPOSITE-OF  ?R )  7E2  ?E 1 ) ) 

Used  in.  ( (DERIV6  :  42  62)  (DERIV7  :  5)  (OERIV13  :  87)) 

(RULE154  (APPROXIMATION-RULE  USEO  2  TIMES) 

«  ( ( 7R  :  COMPARATIVE)  ?C  ?X) 

->  ((!  JPRFDXCOMP  ?R)  7C) 

--  (USE  UNARY  PREDICATE  TO  APPROXIMATE  COMPARISON  WITH  UNKNOWN)) 
Used  in:  ( (DERIV6  :  43)  (OERIV7  :  6)) 
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(RULE  155  (SIMPIIFY-TNON-CONSTANT-RULE  USED  2  TIMES) 

•  ((7q  :  QUANTIFIER  PREDICATE)  7X  TS  TP) 

-X  ?P  IF  I$INDf PENDENT  OF  TP  TX)) 

Used  in:  ( (0ERIV2  :  56)  (0ERIV7  :  7)) 

(RUIE158  (C0NSTRA1N-CH01CE-RULE  USED  0  TIMES) 

•  (ACHIEVE  (?P  :  ( ( ?F  :  PREDICATE)  &  ?L))) 

-> 

(CHOOSE  TX  vsEr'0,t  (?Y  •  <!  {PRIME  ?X ) )  ?S  (J  JSUBST  ?Y  TX  IP)) 
?£! 

if  (jExrsrsP!  ?x  n  (i;  >  jchosent  ?x  ?s  ?e>) 

--  (P  MUST  EXPLICITLY  MENTION  X) 

(IMPLICITLY  USED  IN  DESIV8) 

(TO  ACHIEVE  P  (X)  CONSTRAIN  CHOICE  E  (X)  TO  SATISFY  P  (X))) 

(RULE  157  (MAKE-ASSUMPTION-RULE  USED  1  TIMES) 

•  (•>  ?P  ?Q) 

->  7Q  --  (ASSUME  ?P  IN  (ACHIEVE  (*)  TP  ?Q)))) 

Used  in:  {(OERIV5  ;  50)) 

( RULE  159  (LATERAL-REPHRASE-RULE  USEO  1  TIMES) 

•  (NOT  (EXISTS  ?X  TS  ?P)) 

->  (EMPTY  (SET-OF  TX  TS  TP))) 

Used  in:  ( ( DERIV8  :  2)) 

(RULE  16 L  (TRANSFER-RULE  USED  V  TIMES) 

•  ((7Q  .  QUANTIFIER)  TX  TS  TP) 

->  (TQ  (?Y  :  (!  Q*V  Y))  (PROJECT  TF  TS)  (!  SSUBST  ?Y  T£  TP)) 

IF  (SIN!  ( ?E  ;  (TF  TX))  TP)) 

Used  in;  ( (DERIV4  :  5)) 

(RULE  162  (REC0GNIZE-RU1E  USEO  2  TIMES) 

•  (EXISTS  TX  TS  (*  TE  TX)) 

->  (IN  TE  TS) 

(RECOGNIZING  (■  TE  TX ) 

AS  A  HIGHER-LEVEL  CONCEPT  MAY  8£  BETTER)) 

Used  in:  ((0ERIV4  :  6)  (0ERIV9  :  38)) 

(RUIE163  (INTRODUCE-SPLIT-RULE  FACT-RULE  USEO  1  TIMES) 

•  (RANGE  IOC) 

-> 

(PARTITION  (HANDS  (PLAYERS)) 

(PILFS  (PLAYERS)) 

(SET  nECX  POT  HOLE)) 

--  (ACTUALLY  PARTITION  --  ENUMERATE  CASES  NOT  ELEMENTS)) 

Used  in;  ((DFRIV4  :  9)) 

(RULF164  ( INTRODUCE -SPLIT -RULE  USEO  I  TIMES) 

•  (OIFE  TS l  (DIEF  TS2  TS3)) 

->  (UNION  (DIFF  TSI  TS2)  (INTERSECT  7S1  7S3))) 

Used  in:  ((0ERIV4  :  15)) 

(RULE165  ( INTRODUCE-SPL IT-RULE  USEO  1  TIMES) 

•  (INTERSECT  TS  (SET  ?C)) 

->  (IF  (IN  TC  7S)  (SET  7C)  NIL)) 

Used  in:  ((0ERIV4  :  20)) 

(RULE  169  (PIGEON-HOLE-RULE  USEO  t  TIMES) 

•  (TP  :  (IN  (TE  :  (TF  &  ?L ) )  TS)) 

->  (NOT  <!  {MARX  INVERTED  (IN  TE  (OIEF  (RANGE  TF)  TS)))) 

If  (NOT  (!  {MARXED!  INVERTED  TP))) 

Used  in;  ((0ERIV4  :  7)) 

(RULE  170  (PURE-TRANSPOSE-RULE  USED  1  TIMES) 

•  (PROJECT  TE  (DIEF  TSI  ’S2)) 

->  (OIFE  (PROJECT  7F  TSI)  (PROJECT  TF  TS2) ) 

—  (ASSUMING  TF  IS  INJECTIVE)) 

Used  in:  { ( DERIV*  :  12)) 

(RULE  171  (QUASI  -  TRANSPOSE -RULE  USEO  1  TIMES) 

•  (PROJECT  TF  (SET  J>  TL)) 
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->  (SET  4  (I  SDISTRI8UTE  7X  ?L  (?F  ?X ) ) ) ) 

Used  in:  ((0ERIV4  :  13)) 

(RULE172  ( PART  I At -MATCH -RULE  USED  3  TIMES) 

•  { IN  (?F  ?£)  (PROJECT  ?F  ?S) ) 

->  (IN  ?£  ?S) 

--  (SUFFICIENT  CONDITION  --  NECESSARY  IF  ?F  IS  INJECTIVE)) 

Used  In:  ((DERIV4  :  23)  (OERIVS  :  23)  (OERIV6  :  35)) 

(RULE173  (FACT-RULE  USED  4  TIMES)  •  (IN  ME  (PLAYERS))  ->  T) 

Used  in:  ( (DERIV4  :  24)  (OERIVS  :  24)  (OERIVS  :  27  38)) 

(RULE176  (SIMPL I FY-TNON -CONSTANT -RULE  USED  5  TIMES) 

••  ( ?X  :  NIL) 

•  (?E  :  (JOIN  &  7ETC) ) 

->  (I  IREMOVE  ?X  ?E ) ) 

Used  in:  ( (DERIV2  :  8) 

(DERIV3  :  78) 

(DERIV4  :  39  49) 

(DERIVIO  :  18)) 

(RULE  177  ( SIMPL I FY-TNON -CONSTANT -RULE  USED  12  TIMES) 

••  (?P  :  ((?0  :  COMM-CONN)  &  ?L ) ) 

•  ( ?Q  :  (70  8  ?M ) ) 

->  (TO  &  ?L  4  (!  SREMOVE  TP  ?M ) ) 

--  ((TO  (TO  4  TL)  4  TS)  ->  (TO  4  TL  4  ?S))) 

Used  in:  ((0ERIV3  :  45) 

(DERIV4  :  28  33) 

(DERIV5  :  31) 

(DERIV6  :  39) 

(DERIVt  t  :  17) 

(0ERIV13  :  59  63  66  89  103) 

(0ERIV14  :  38)) 

(RULE178  (SIMPLIFY-7N0N-C0NSTANT-RULE  USED  18  TIMES) 

•  (COMM-CONN  TE) 

->  TE) 


( (DERIV2 

9  35  54  61  71  87) 

(0ERIV3 

15  79) 

(0ERIV4 

50) 

(DERIV5 

37) 

(DERIVE 

14  20) 

(DERIV9 

46) 

(0ERIV11 

:  14) 

(0ERIV13 

:  37  54) 

(QERIV14 

:  21  65)) 

(RULE  1 79  (OPPORTUNISTIC -EVALUATION -RULE  USED  6  TIMES) 

•  ( ( TR  :  REFLEXIVE)  TE  TE) 

->  T) 

Used  In:  ((0ERIV3  :  73) 

(0ERIV5  :  33  48) 

(OERIVS  :  56) 

(0ERIV9  :  34) 

(0ERIV14  :  66)) 

(RULE180  (FACT-RULE  USED  1  TIMES) 

•  (AT  CARO  DECK) 

->  NIL  IF  (ROUND-PROGRESSING)) 

Used  in:  ((DERIV4  :  38)) 

( RULE  182  (PROPAGATE-SPLIT-RULE  USED  2  TIMES) 

•  (IN  TC  (SET  4  TL)) 

->  (OR  4  [ !  JDISTRIBUTE  TXX  TL  (•  TC  TXX)])) 
Used  in:  ( (DERIV4  :  32)  (DERIV13  :  36)) 

(RULE  184  (OPPORTUNISTIC-EVALUATION-RULE  USED  3  TIME5) 
••  T  •  (OR  4  71) 

->  T) 

Used  in:  ((0ERIV3  :  27  32)  (DFRIV4  :  25)) 

(RULE  185  (SIMPLIFY-7N0N-C0NSTANT-RULE  USEO  2  TIMES) 


4 


§B.4.  List  of  Rules 


Used  in: 
(RULE187 


Used  in: 
(RULE133 


Used  in: 
(RULE  189 

Used  in: 
(RULE  190 


Used  in: 
(RULE  192 

Used  in: 

( RULE  193 

Used  in: 
(RULE  194 

Used  in: 

( RULE  195 

Used  in: 
(RULE  196 

Used  in: 


•  (IF  E  ?X  ?Y) 

->  ?X) 

((DERIV4  .  ?6)  (DFRIV14  ;  67)) 

(TRANSFER-RULE  USED  1  TIMES) 

••  (?S1  ■  (SET  &  ?L 1 ) ) 

•  ( ( ?U  :  UNION)  4  ?L) 

->  (?U  (SET  4  ?L1  &  ?L2)  &  (!  SREMOVE  ?Sl  (!  SREMOVE  TS2  ?L ) ) ) 

IF 

(SEXISTS!  (!!  ?S2  :  (SET  4  ?L2 ) ) 

(!  JFOLLOWING  ?S1  ?L) 

(!!  SOIFE -NODE !  ?S1  ?S2 ) ) 

—  ((UNION  (SET  A)  (SET  8)  4C) 

->  (UNION  (SET  A  8)  4C))) 

((DERIV4  :  29)) 

( SIMPL I FY->NON -CONSTANT -RULE  USED  2  TIMES) 

•  ((?0  :  COMM-CONN)  4  ?L) 

->  (?0  4  (!  SREMOVE  ?S2  ?L ) ) 

IF 

(S EXISTS!  ?S1  7L 

(!!  SEXISTS!  ?S2  ( !  SFOLLOWING  ?S!  ?L) 

(!!  AND  (!  SEQ!  ?S1  ?S2)  (!  SDIFF-NOOE!  ?S1  ?S2 ) ) ) ) 
--  (ELIMINATE  DUPLICATES)) 

((DERIV2  .  70)  (DERI VI 3  ;  90)) 

(DETECT -APPLICABILITY  DISJOXNT-SUBSETS-RULE  USED  1  TIMES) 

••  (?S  :  SSET !  SUNKNOWN!) 

•  (?P  :  ( ( ?Q  :  PREDICATE  (-  DISJOINT)) 

4  ?M)  ) 

->  ( !  SREEORMULATE  7P  (DISJOINT  ?S  (!  Q*V  S ) ) ) 

IF  (STRANSFORMABLE!  ?P  (DISJOINT  ?S  ?H) ) ) 

( ( DERTV9  :  2)) 

(CONTROL-RULE  USED  l  TIMES) 

•  ( ?G  :  (SHOW  T ) ) 

->  (!  SRETURN  ?R  TQ) 

IF 

(ANO  [ !  STRANSFORMEOI  ?P  TQ  TG] 

[!  NOT  ( !  SINP!  (!!  ?X  :  SUNBOUNO- VAR ! )  ?Q)]) 

--  (PROCESS  OF  MATCHING  ?P  ANO  ?Q  SHOULO  BIND  VARIABLES  IN  TQ)) 

( (0ERIV9  :  17)) 

(PARTIAL -MATCH-RUI  E  USED  3  TIMES) 

•  (*  ((TQ  :  QUANTIFIER  PREDICATE)  TX  TS  TP)  ( TQ  ?Y  TS  TR ) ) 
->(■(!  SSUBST  TY  TX  TP)  TR) 

--  (SUFFICIENT  (NOT  NECESSARY)  CONDITION  --  QUANT  I F ICATIONT ) ) 
((DERIV2  :  83)  (0ERIV9  :  6)  (DERIV13  :  74)) 

(REDUCE-TSUFF -CONO-RULE  USED  l  TIMES) 

•  (•  TP  (IN  (TX  :  SVAR!)  TS)) 

->  (■  TS  (SET-OF  TX  (DOMAIN  'X  TP)  TP))) 

( ( DERIV9  :  7)) 

(VARIABLE-RULE  USED  7  TIMES) 

•  (•  (TX  :  SUNBOUND-VAR! )  TE) 

->  ( !  SB IND-VAR  TX  TE)) 

( (0ERIV3  :  53  56) 

(QERIV9  :  13  16) 

(DERI VI l  :  3  12) 

(DERIV13  :  38)) 

(FUNCTIONAL-DOMAIN-RULE  USED  1  TIMES) 

•  (DOMAIN  TX  (TF  4  ?L ) ) 

->  (DOMAIN  TX  TE) 

IF  (SEXISTS!  (!!  TE  :  ( TG  4  TM ) )  TL  (!!  SIN!  TX  7M) ) ) 

( (0ERIV9  :  9)) 

( FUNCTIONAL -OOMAIN-RULE  USED  1  TIMES) 

•  (DOMAIN  TX  (TF  TX)) 

->  (DOMAIN  TF)) 

( (DERIV9  :  10)) 
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(RULE  197 

Used  in: 
(RULE198 

Used  in: 
(RULE  199 

Used  in: 
(RULE200 


Used  in: 
(RULE202 

Used  in: 
(RULE203 


Used  in: 
(RULE204 

Used  in: 
(RULE205 

Used  in: 
(RULF207 

Used  in: 
(RULE208 

Used  in: 
(RUI  E210 


(FUNCTIONAL -OOMAIN-RULE  FACT-RULE  USED  1  TIMES) 

•  (OOMAIN  SUIT-OF) 

->  (CAROS)) 

((OERIV9  :  U)) 

(OISJOINT-SUBSETS-RULE  USED  1  TIMES) 

•  (DISJOINT  ( ?H  :  SUNKNOWN!)  ?S) 

->  (PR-OISJOINT  ?H  ,'S  (COMMON-SUPERSET  ?H  ?S)) 

--  (ASSUME  ?H  AND  OR  ?S  CHOSEN  RANDOMLY  FROM  ?U) 

(SIZE  OF  COMMON  SUPERSET  ?U  SHOULD  BE  KNOWN)) 

((0ERIV9  :  21)) 

(INTERSECTION-SEARCH-RULE  USED  1  TIMES) 

•  (COMMON-SUPERSET  (SET-OF  ?X  ?S  ?P)  (SET-OF  ?Y  ?S  ?Q ) ) 

->  ?S) 

( (DERIV9  :  25)) 

(REFINE  DISJOINT-SUBSETS-RULE  USED  1  TIMES) 

•  (?E  :  (PR-DISJOINT  (?H  :  SUNKf.OWN!)  ?S  ?U ) ) 

-> 

(!  tTRY  ?E  (■  ?H  (FILTER  ?H  (?P  :  (!  SSELECT  ?L)))) 

(PR-OISJOINT  ?H  (FILTER  ?S  ?P)  (FILTER  ?U  ?P))) 

IF 

(SNON-EMPTY!  (?L  : 

(!  SSET-OF  (!!  ?P  :  SUNARY t } 

( !  SPREOICATES) 

(!!  !  STRYABLEt  ?E  (■  ?H  (FILTER  ?H  ?P)))))) 

--  (IMPROVES  ACCURACY  BY  NARROWING  OOWN  SETS  ?S  AND  ?U) 

(SHOULD  ALSO  REOUIRE  (SUBSET  ?U  (DOMAIN  ?P ) ) 

ANO  (KNOWN  («  (FILTER  ?U  ?P))))) 

( (DERIV9  :  27)) 

( FUNCTIONAL -DEPENDENCE- RULE  USED  1  TIMES) 

•  (EVAL  ( ?E  :  ( ( ?F  .  FORMULA)  &  ?L ) ) ) 

-> 

(FUNCTION-OF  (?V  :  (I  SFII.L-IN  'Independent  variable")) 

(DEPENDENCE  ?E  ?V))) 

((DERIV9  :  44)) 

(DEPENDENCE-RULE  USED  I  TIMES) 

•  (DEPENDENCE  (?E  :  (?F  8  ? L ) )  (?V  :  SATOM I ) ) 

-> 

(D*  8 

( !  SDISTRIBUTE  ?EI  (!  SSET-OF  7X  ?L  ( ! !  SINP!  ?V  ?X ) ) 

( ! !  □*  (DEPENDENCE  ?EI  ?V) 

(DEPENDENCE  (?F  8  (!  $ARGL<E  ?E ) ) 

( !  SCORRESPONOING  (!  SARGL<E  ?E)  ?L  ?EI)))))) 

( (DERIV9  :  46)) 

(DEPENDENCE -RULE  USEO  2  TIMES) 

•  (DEPENDENCE  ?E  (?V  :  SATOMI)) 

->  NIL  IF  (NOT  ( !  SINP!  ?V  ?E ) ) ) 

( (0ERIV9  .  51  5b)) 

(DEPENDENCE-RULE  USEO  2  TIMES) 

•  (DEPENDENCE  ( ( 7F  :  INCR1-DECR2)  ?E1  ?E2)  ?V) 

->  (D+  (DEPENDENCE  ?E I  7V)  (D-  (DEPENDENCE  >E2  7V) ) ) ) 

((OERIV9  :  50  55)) 

(DEPENDENCE -RULE  USEO  I  TIMES) 

•  (DEPENDENCE  (INCR1  ?E  8  ?L )  (?V  :  SATOM!)) 

->  (DEPENDENCE  7E  7V) 

IF  (NOT  ( !  SIN!  7V  ?L))) 

( (DERIV9  :  54)) 

(OFPENOENCE-RULE  USED  l  TIMES) 

•  (DEPENDENCE  7E  ?E) 

->  INCREASING) 

( (0ERIV9  :  57)) 

(FIX-UP  FUNCTIONAL -DEPENDENCE-RULE  USEO  1  TIMES) 
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Used  in: 
(RULE211 


(RULE212 


Used  in: 
(RULE213 

Used  in: 
(RULE21S 

Used  in: 
(PUI E216 

Used  in: 
(RUI  E218 

Used  in: 
(RULE219 

Used  in: 
(RULE220 

Used  in: 


•  (FUNCTION-OF  ?V  ?E) 

->  ( FUNC T 1  ON -OF  ?W  ( !  SSUBST  INCREASING  ?0  ?£ ) ) 

IF 

(SEXISTSPI  ( !  I  ?D  :  (DEPENDENCE  (?W  :  (?F  &  Hi)  ?V)) 

?E  (!!  SIN!  ?V  ?L)) 

—  (IDEALLY  ?V  IS  AN  OBSERVABLE  PROPERTY  Of  ?V)) 

((0ERIV9  :  47)) 

(FUNCTIONAL -RECURRENCE -RULE  USED  0  TIMES) 

(?E  : 

(-  (?£1  :  ( ?G  3.  .'ETC)) 

(?£2  :  ((? H  :  JUNOOUND-VAR! ) 

<?W  :  (?F  &  ?L) ) )  )  )  ) 

-> 

(’  STRY  ?E  (*  ?V  ?W) 

(•  'H  (LAMBDA  ((’XX  ;  (!  Q*V  ?F ) ) )  (!  SSUBST  ?XX  ?V  ?E1)))) 

IF 

(SEXISTSP!  (  !  !  ?V  :  (?F  &  ?M)  ) 

? E 1  ( ! !  STRYABLE!  7E  (*  ?V  ?W) ) ) 

--  (?W  MATCHES  SUB-EXPRESSION  ?V  OF  ?El) 

(•  (?G  -•  ?V  --)  ( ?H  ?W ) ) ) 

(FUNCTIONAL -RECURRENCE-RULE  USFO  t  TIMES) 

• 

(’£  : 

(-  (’El  :  { ?F  &  ?L ) ) 

( ?E2  :  ((’H  :  SUNBOUNO-VAR! ) 

(’W  .  (?G  &  ’ETC)))))) 

-> 

(!  STRY  ?E  (■  ’El  ’V) 

(*  'H  (INVERSE  (LAMBDA  ( ( ?XX  :  (!  Q*V  ?F )  ) )  (!  SSUBST  ’XX  ?V  ?W ) ) ) ) ) 
IF 

(SEXISTSP!  (! 1  ’V  :  (?F  1  ?M ) ) 

’W  ( ! !  STRYABLE !  'E  (*  ?E1  ’V))) 

--  (?Et  MATCHES  SUB-EXPRESSION  ’V  OF  ?M) 

<*  ’El  (?H  (’G  --  ’V  --)))) 

( (DERIV9  5)) 

(HEURISTIC-EQUIVALENCF-PRESFRVING-RULE  USED  1  TIMES) 

•  ((LAMBDA  (4  7ARGS)  ’BODY)  S  ?L) 

->  (!  SSUBSTL  ?L  ’ARGS  7BOOY) 

IF  (SEQUAL-LENGTH!  ’ARGS  ?L ) ) 

((DERIV14  86)) 

(HEUR IS  TIC -EQUIVALENCE- PRESERVING-RULE  USED  I  TIMES) 

•  (LAMBDA  (’X)  ( ?F  ’X)) 

->  ?F) 

((0FRTV9  :  15)) 

( SIMPLIFY-SNON-CONSTANT -RUt  E  USED  I  TIMES) 

••  (?W  :  ((INVERSE  ?F)  ’X)) 

•  (’F  ?W) 

->  ’X) 

((OERIV9  :  19)) 

(LATERAL-REPHRASE-RULE  USED  1  TIMES) 

•  (*  ?S  (FILTER  ?S  ?P ) ) 

->  (■>  (IN  (?X  :  ( !  Q*V  <))  ?S)  (?P  ’X))) 

( (0ERIV9  :  28)) 

(TRANSFER-RULE  USED  1  TIMES) 

•  (FORALI  ’XI  (SET-OF  7X2  ?S  ’P)  ?Q) 

->  (FORALL  ’XI  ?S  (->  (!  SSUBST  ?X1  7X2  ?P)  ?Q ) ) ) 

((OERIV2  :  79)) 

(PURE -TRANSPOSE -RULE  USEO  1  TIMES) 

•  (*>  ?P  ( ( ?F  :  QUANTIFIER)  ?X  ?S  7Q) ) 

->  (?F  ’X  ?S  (■>  ?P  ?Q) ) 

--  (SPECIAL  CASE  OF  RULE329 ) ) 

((OERIV2  :  46)) 
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(RULE221  (MAKE  -  ASSUMPTION- RULE  USEO  1  TIMES) 

•  (?G  :  (SHOW  ?X ) ) 

->  (!  {ASSUMING  ?X  T  (!  SRETURN  TP  T)) 

IF  (SSUFFICEO!  TP  ?g  TG) ) 

Used  in:  ((DERIV13  :  24)) 

(RULE224  (REOUCE-TSUFF-CONO-RULE  US£0  1  TIMES) 

•  (•>  (AND  &  ?L )  (?P  .  (?F  A  ?M) ) ) 

->  (->  ?Q  ?P) 

IF  (SEXISTS!  ?Q  ?L  (!!  SINP!  ?F  ?Q))) 

Used  in:  ((OERIVU  :  8)) 

(RUIE225  (RFOUCE-)SUFF-CONO-RUI  E  USED  1  TIMES) 

•  (•>  ( ?C  :  (OR  &  ?l ) )  (?P  :  <?F  i  ?M))) 

-■>  (ANO  [NOT  ( !  {REMOVE  ?Q  TC)]  [■>  ?Q  ?P]) 

IF  (SEXISTS!  ?Q  ?L  (!!  SINP!  ?F  7Q))) 

Used  in:  ((OERIVU  :  10)) 

(RUIE226  (REDUCE-TSUFF-CONO-RULE  USEO  I  TIMES) 

•  (■>  (■>  ?C  TO)  (?P  { ?F  i  ?M) ) ) 

->  (ANO  7C  [■>  ?0  TP]) 

IF  (SINP!  TF  TO)) 

Used  in:  ((OERIVU  :  9)) 

(RULE227  (SUFFICIENT-CONOITION-RULE  USEO  1  TIMES) 

•  (TE  :  (EVAL  ( TQ  :  ((TF  :  PREDICATE)  &  TETC)))) 

-> 

(!  STRY  TE  (?R  .  (!  {INSTANTIATE  (!  SSEIECT  TS ) ) ) 

(EVAL  (■>  7R  TQ))) 

IF 

({NON-EMPTY!  (TS  : 

( !  SSET-OF  TP  (!  {PREDICATES) 

(!!  SINP!  TF  ( !  $ROOY<FN  TP)))))) 

Used  in:  ((OERIVU  :  I)) 

(RULE228  (FACT-RULE  USED  l  TIMES) 

•  (TE  :  (l€GAL  TP  ?C)) 

->  ( !  {SUFFICE  TE  (■  K  (CARD-OF  TP))) 

IF  ( {TRYA8LE !  TE  («  TC  (CARO-OF  TP))) 

--  ((LEGAL  P  (CARO-OF  P ) )  IS  A  LEMMA)) 

Used  in:  ((OERIVU  :  2)) 

(RULF234  (HISTORY-RULE  USEO  1  TIMFS) 

•  (TP  :  (PREDICATE  S  TETC)) 

-> 

( !  {TRY  TP 

(NOT  (DURING  ( !  {INSTANTIATE  (TA  :  (!  {SELECT  (:  {ACTIONS)))) 
(UNDO  TP))) 

(WAS-DURING  (CURRENT  ?A)  TP))) 

Used  in:  ((0ERIV12  :  1)) 

(RUIE236  (SYSTEMATIC-EVALUATION-RULE  USED  18  TIMES) 

•  ((TF  :  COMPUTABLE)  &  TL) 

->  (!  {APPLY  TF  TL) 

IF  (SCONSTANTL!  TL)) 

Used  in:  ((DERIVE  :  51) 

(DERIV3  :  31  34  57  -  58  ;  74  76  85) 

(DERIV8  :  57) 

(DERIV9  :  52  58  -  59) 

(DERIV10  :  U) 

(OERIVU  :  12) 

(OERIVU  :  34) 

(OERIVU  :  34  75  77)) 

(RULE238  (REOUCE-)NON-EQUIVALENT-RULE  USEO  l  TIMES) 

•  (TC  :  (CHOOSE  TX  TS  TE)) 

->  ( !  {MARX  (CHOOSE  TC  TS  TE)  TE) 

—  (SUBSUMES  RULE  132  ANO  RULE  158) ) 

Used  in:  ( (OERIVU  :  13)) 

(RULE2S3  (SIMPIIFY-TNON-CONSTANT-RULE  USEO  l  TIMES) 

•  (lfl:U8  TL  TL) 
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Used  in: 
(RUl F254 


Used  in: 
(RUL  E 2 55 

Used  in: 
(RULE256 


Used  in: 
(RUIE258 

(RULE266 


) 

Used  in: 

( RULE  267 

Used  in: 
(HULE268 

Used  in: 


->  (SET  ?l ) ) 

( ( DE  R I V 13  :  35)) 

(ACTION  RULE  USED  l  TIMES) 

•  ( ?E  :  (CHANGE  ?P)) 

-> 

( !  STRY  ?E 

(•>  ( ?ACT ION  :  {»  SINSTANTIAT E  (!  SSELECT  (!  SAC  T I  QMS ) ) ) )  7£ ) 
FACTION) 

IF 

(SEXtSTS!  ?ACT  (!  SACTIONS) 

(!  STRYABLE!  ?E  (•>  (?ACT  4  'ETC)  7E)))) 

((OERrV3  :  46)) 

( SIMPL I FY->NON -CONST ANT- RULE  USED  1  TIMES) 

•  U ?0  QUANTIFIER  PREDICATE) 

7X  (COLLECTION  ?C) 

?P) 

->  ( !  SSUBST  ?C  ?X  ?P ) ) 

((OERIV2  :  104)) 

(INTRODUCE  SPLIT-RULE  DESIGN-CHOICF -RUl E  USED  i  TIMES) 

•  (7P  :  (PREDICATE  4  ?ETC)) 

-> 

(•  JASSUMING 

(SELECT  (?X  :  (•  Q*V  (7E  :  ('  SSELECT  ?L ) ) ) )  (RANGE  ?F ) ) 

T  (AND  [•  ?E  7X]  [ !  SSUBST  7X  ?E  ?P])) 

IF  (SNON-EMPTY!  (?L  :  (!  JSET-OFP  (!!  ?E  &  ?ARGS )  ?P  T ) ) ) 

(CHOOSE  VALUE  ?X  FOR  :E  BEFORE  CONSTRUCTING  THE  OBJECT  ON  WHICH  ?E 
DEPENDS)) 

( (OERIV1J  :  58)) 

(INTRODUCE-SPLIT-RULE  TEMPORAL-GOAL  -  RULE  USED  0  TIMES) 

•  ?P  ->  (AND  [•'  ( NO  T  ?P)  (CAUSE  7P)]  [O  7P  (NOT  (UNDO  ?P ) )  ] ) 

--  (COULD  HAVE  SEEN  USED  IN  DER I V 1 4  ) 

(TO  ACHIEVE  GOA l  P  AT  f NO  OF  INTERVAL)) 

(TEMPORAL -GOAL-RULE  USED  1  TIMES) 

•  (7P  •  (ACHIEVE  (PREDICATE  4  7 ETC) ) ) 

-> 

(FORAU  ( ?T  :  (!  Q*V  T)) 

(I  B  UB  0  (-  (rf  7S)  1)) 

<(?Q  : 

( !  SSUBST  (LAMBDA  ((?J  :  (!  Q*V  J)))  (TREFIX  ?S  ?J) ) 

?S  ?P) ) 

?T)) 

IF  (SIMP'  (ff  :$  :  SEQUENCE)  ?P) 

(CONVERT  STATIC  SEQUFNCE  CONSTRAINT  P  TO  TIME-VARYING  GOAL  PREDICATE  Q) 
((DFRIV14  :  l)) 

(RECOGNIZE-RULE  USEO  3  TIMES) 

•  (LAMBDA  7ARGS  7BOOY) 

->  7F  IF 

(SEXISTS!  7F  (!  $FNS<E  7BOOY)  (!!  !  SRECOGNI7ABL  E !  ?B0DY  ?F ) ) ) 

( ( DERIV 14  :  3  -  4  ;  14)) 

(CONTROL-RULE  USED  20  TIMES) 

•  ?E  ->  (!  SCONSIOER  ?E) 

--  (FOCUS  MECHANISM  FOR  CONVENIENCE)) 

((DERIV3  .  13  64) 

(DFRIV4  :  8  19  43) 

(DERIV5  :  5  36) 

(OERIV6  :  23) 

(0ERIV9  :  22) 

(DERIV10  :  U  25) 

(DERIV13  :  82  UO) 

(DERIV14  :  2  9  28  39  -  40  :  52  83)) 


( RULE  269  ( CONTROl  -RULE  USED  20  TIMES) 
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•  (?E  :  (CONSIDER  ?N)) 

->  ( !  SRETURN  ?0  ?N) 

IF  (SCONSIDERED!  ?£  ?0) 

--  ( REMEMBERS  70  ->  ?N  FOR  LATER  USE) 

(DEFOCUS  MECHANISM)) 

Used  in:  ((DERIV3  :  35  77) 

(DERIV4  :  27  30  55) 

(DERIV6  :  28  51) 

(DFRIV6  :  38) 

(0ERIV9  :  26) 

(OERIVIO  :  22  31) 

( OF R IV 1 3  :  88  115) 

(DERIV14  :  35  37  46  51  80  -  81  ;  87)) 

(RULE271  (VARIABLE-RULE  USED  7  TIMES) 

•  ('  ?f  (?X  :  IUN80UN0-VAR! )) 

->  ( !  S8IN0-VAR  ?X  ?E ) 

--  (MIRROR  OF  RULE  194) ) 

Used  in:  ((0ERIV2  :  31  -  32  ;  49  -  50  ;  84) 

(0ERIV3  :  54) 

(DERIV13  :  75)) 

( RULE273  (OEFUNCTIONALIZE-RULF  USED  1  TIMES) 

•  ( ?F  ?X) 

->  (!  SSUBSTL  ( !  ^DISTRIBUTE  ?G  ?S  (?G  ?X ) )  ?S  ?F) 

IF  (SNON-EMPTY!  ( ?S  :  (!  JSET-OFP  ( ! !  ?H  :  SUNAPPLIFO!)  ?F  T ) ) ) 
--  (APPIY  FUNCTIONS  G  CONTAINED  IN  FUNCTIONAL  F  TO  ARGUMENT  X)) 
Used  in:  ( ( OCR  TV  14  :  82)) 

(RULE274  ( INTROOUCE-SPLIT-RULE  USED  l  TIMES) 

•  (PREFIX  ?S  (♦  71  1)) 

->  (APPEND  (PREFIX  ?S  71)  (LIST  (NTH  ?S  (♦  71  1))))) 

Used  in:  ((0ERIV14  ;  12)) 

(RULE276  ( I NTRODUCE -SPL I T- RUL £  TEMPORAL -GOAL -RULE  USED  1  TIMES) 

•  (?P  :  (PREDICATE  &  7ETC ) ) 

-> 

(OR  [ANO  [NOT  (CHANGE  (?E  :  (!  SCAOR  (?N  :  (!  SSELECT  ?S)))))] 

[ !  SSUBST  'f.  ?H  ?P]  J 
(ANO  [CHANGE  ?E]  ?P]) 

IF  ( SNON -  EMPTY !  (?S  :  (I  SSET-OFP  (II  7N  :  (NEXT  ?F))  ?P  T) ) ) 

--  (SPLIT  ?P  INTO  2  CASES  DEPENDING  ON  WHETHER  ?E  CHANGES)) 

Used  in:  ((0ERIV14  :  8)) 

(RULE277  (REDUCE  OSUFF-COND-RULE  USED  1  TIMES) 

•  (CHANGE  ( ?E  :  ( ( ?F  :  EXTREME )  ?S ) ) ) 

->  ((!  SCOMPARATIVE-OF  ?F)  ( ?F  (CHANGE  ?S ) )  ?E ) 

--  (EG  (MAX  S)  CHANGES  IFF  (MAX  (CHANGE  S ) )  >  (MAX  S))) 

Used  in:  ( ( OCR IV14  :  42)) 

(RULE278  (PURE-TRANSPOSE-RULE  USFO  0  TIMES) 

•  (CHANGE  ( (  7F  :  SPROJECTION!)  ?S ) ) 

->  { ?F  (CHANGE  ?S ) ) 

--  (ASSUMING  (F  (CHANGE  S) )  ANO  (F  (OLD  S) )  ARE  DISJOINT)) 

( RULE279  (FACT-RUIE  USED  2  TIMES) 

•  (CHANGE  CANTUS  -  l ) 

->  (LIST  (NEXT  NOTE)) 

--  (SHORTCUT  --  COULD  RE  DERIVED  FROM  DEFINITION  OF  CANTUS- 1)) 
Used  in:  ((0ERIV14  :  44  58)) 

(RULE230  ( PURE -TRANSPOSE -RUI F  USFD  0  TIMES) 

•  ( ( ?F  :  SPROJECTION!)  (COLLECTION  &  ?L)) 

->  (COLLECTION  8  (!  SOISTRIBUTE  ?X  ?L  ((!  SSINGULAR-OF  ?F) 

?*)))) 

(RULE281  ( S IMPL I FY-XNON- CONSTANT -RULE  USED  2  TIMES) 

•  (ONE-OF  (COLLECTION  ?C ) ) 

->  7C ) 

Used  in:  ((0ERIV14  :  45  59)) 

(RULE282  (TEMPORAL-GOAL-RULE  USED  l  TIMES) 
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Used  in. 
(RULE283 

Used  in; 
( RULE  284 


Used  in: 


(RULE285 

(RULE287 

Used  in: 
(RUIE288 

Used  in: 

( RULE  289 

Used  in: 
(RULE290 

Used  In: 
(RULE291 

Used  in: 
(RUl E292 

Used  in: 
(RULE293 

Used  In: 


•  (ACHIEVE  ?P) 

->  (NEXT  ?P)) 

((DERIVI4  :  5)) 

(PURE  TRANSPOSE -RULE  USED  2  TIMES) 

•  (NEXT  (?E  :  (?G  &  ?l  ))  ) 

->  ( !  SSUBSTL  (•  SDISTRIBUTE  ?F  ?S  (NEXT  ?F ) )  ?S  ?E) 

IF  (SNON-EMPTY!  ( ?S  :  (!  SSET-OF  ('!  ?H  :  SFUNCT IONAL ! )  7L  T)))) 
( (OERIV14  :  6  -  7)) 

(QUASI -TRANSPOSE-RULE  PROPAGATE -$Pl I T-RUL E  USED  9  TIMES) 

••  (?S  :  (JOIN  &  ?L ) ) 

•  (7E  :  ((?F  :  HOMOMORPHISM)  &  ?M)) 

-> 

(( !  SADD-OF  ?F) 

&  (!  SDISTRIBUTE  ?X  ?L  ( ! !  !  SSUBST  ?X  ?S  ?E ) ) ) 

((F  (*  X  Y)) 

->  (♦  (F  X)  (F  Y) ) 

WHERE  ♦  OPERATIONS  MAY  QE  DIFFERENT  FOR  (DOMAIN  F) 

ANO  (RANGE  F ) ) ) 

( (OER  IV2  :  6  102 ) 

(DERIV4  :  21  31) 

(DERIV5  :  7) 

(0ERIV6  :  4) 

(0FRIV13  :  106) 

(OER I V 14  :  18  62)) 

(FACT-RULE  USEO  0  TIMES) 

•  (NEXT  CANTUS- 1) 

->  (APPEND  CANTUS- 1  (LIST  (NEXT  NOTE))) 

--  (THIS  CAN  8E  DERIVED  FROM  DEFINITION  OF  NEXT)) 

(PROPAGATE-SPLIT-RULE  USED  2  TIMES) 

•  ?E  ->  (IF  ?B  ( !  SSUBST  ?X  ?C  ?E )  (!  SSUBST  ?Y  ?C  ’()) 

IF  ( S I NP !  (!!  ?C  :  (IF  ?8  ?X  ?Y ) )  ?E ) ) 

((DERIV14  .  22  25 ) ) 

(OPPORTUNISTIC-EVAtUATION-RULE  USED  2  TIMES) 

•  (»  (COLLECTION  &  ?L ) ) 

->  ( !  LENGTH  ?L ) ) 

((0FRIV14  :  24  68)) 

( OPPORTUNISTIC -EVALUATION -RULE  USED  1  TIMES) 

•  (*  NIL) 

->  0) 

((DERIV14  :  23)) 

(HEURISTIC-EQUIVALENCE-PRESFRVING-RULE  USEO  2  TIMES) 

• 

( ( ?R  :  NUMERICAL  PREDICATE) 

(+  ?E  (?C1  :  SCONSTANT! )) 

( ?C2  :  SCONSTANT!)) 

->  (?R  ?E  (S  -  ?C2  ?C 1 ) ) ) 

( (OERIV14  :  27  69)) 

(RECOGNIZE-RULE  USEO  3  TIMES) 

*  (-  (#  (SET-OF  ?X  ?S  ?P ) )  0) 

->  (NOT  (EXISTS  ?X  ?S  ?P ) ) ) 

( (OERIV13  :  113)  (OERIV14  .  30  71)) 

(RFC0GNI7E-RULE  USED  4  TIMES) 

*  (EXISTS  ?X  ?S  (*  7X  7E ) ) 

->  (IN  ?E  ?S) 

—  (MIRROR  OF  RULE  162 ) ) 

( (DERIV13  :  86  114)  (0ERIV14  :  31  72)) 

( OPPORTUNISTIC -EVALUATION -RULE  USED  1  TIMES) 

*  (IN  (ONE-OF  ?S)  ?S) 

->  T) 

( (0ERIV14  :  33)) 
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(RULE294  (RECOGNIZE-RULE  USEO  1  TIMES) 

•  (IF  ?C  NIL  ?Y) 

->  (AND  ?Y  [NOT  ?C])) 

Used  in:  ((0ERIV14  :  36)) 

(RULE296  (PURE-TRANSPOSE-RULE  USED  1  TIMES) 

•*  (?N1  :  (NOT  ?P ) ) 

•  (AND  i  ?L ) 

->  (AND  &  [!  SREMOVE  ?Nt  (!  SREMOVE  ?N2  ?L )  ]  [NOT  (OR  ?P  ?0)]) 
IF  (SIN!  (!!  ?N2  :  (NOT  (?Q  :  (-  ?P ) ) ) )  ?L)) 

Used  in:  ((DERIV14  :  47)) 

(RULE297  (PROOI  EM-MFRGING-RUl  E  FUNCTIONALIZE -RULE  USEO  1  TIMES) 

•  ( ( ?B  :  BOOLEAN-OP)  (?P  ?E 1  ?E2)  ( ?Q  ?E1  ?E2 ) ) 

->  ( ( ?B  ?P  ?Q)  ?E1  ?E2) ) 

Used  in:  ( ( OERTV14  :  48)) 


(RULE298  ( FUNCTIONAL IZE -RULE  USED  1  TIMES) 

•  (NOT  (?P  &  ?L ) ) 

->  ((NOT  ?P)  &  ?L) ) 

Used  in:  ( ( DFR I V 14  :  49)) 

(KULE299  (FACT-RULE  USFO  1  TIMES)  •  (NOT  (OR  HIGHER  •))  ->  LOWER) 
Used  in:  ((0ERIV14  :  50)) 


( RULE 300  (SPECIAL-CASE-REDUCTION-RULE  TEMPORAL -GOAL-RULE  USED  1  TIMES) 
•  (?E  :  (NEXT  (?0  :  ( ( ?F  :  EXTREME)  ?S ) ) ) ) 

-> 

( !  STRY  ?E  ((!  SCOMPARATIVE-OF  ?F) 

( ?N  :  (7F  (CHANGE  ?S ) ) ) 

?0) 

?N) 

--  (ASSUMES  ?S  IS  EXPANDING)) 

Used  in:  ((0ERIV14  :  55)) 


(RULE30I  (ALL  PURPOSE-RULE  USED  14  TIMES) 

•  ?N  -) 

(  !  SHARK 

( ?Nl  <-  ( 7N2  :  (!  SFILL-IN  'Equivalent  node  derived  earlier"))) 
?N2) 

IF 

(SFQ!  ’N  ( ?  N 1  :  (!  SFILL-IN  "Earlier  node  eitti  same  expression"))) 
--  (?N2  WAS  OERIVED  FROM  ?N1  OR  VICE  VERSA)) 

Used  in:  ((0FRIV2  :  18  65  68  92) 

(0FRIV5  :  l  42  46  -  47) 

(0ERIV7  :  4) 

(OERIVIO  :  14) 

(DFRIV13  :  107) 

(DERIV14  :  54  60  -  61)) 


(RULE302  (CONTROL-RULE  USEO  2  TIMES) 

*  ?P  ->  T  IF  (SINP!  ?P  ( !  SSTATES ) ) 


(NOTE  THAT  SINP!  TEST  AS  STATED  WITHOUT  RESTRICTIONS  WILL  ALWAYS 
SUCCEED) 

( VALIO  ONLY  IF  ?P  IS  PREMISE)) 

Used  in:  { (0ERIV14  :  56  74)) 


(RULE303  (SPECIAL-CASE-REDUCTION-RULE  USED  0  TIMES) 

•  ( ?F  :  (SET-OF  ?X  ?S  ?P ) ) 

->  (!  STRY  ?E  (NOT  (EXISTS  ?X  ?S  ?P) )  NIL)) 


(RULE304  (CHECK-NEC-CONO-RULE  USED  1  TIMES) 

*  (?E  :  (IN  ?X  ?S) ) 

-> 

( !  SCHECK  ?E 

(NOT  ((?P  :  (I  SSELECT  7L)) 

?X  ((!  SSUPERLATIVE -OF  7P)  ?S)))) 

IF 

(SNON-EMPTYI  (7L  : 

(I  SSET-OF  (II  ?P  :  ANTI-SYMMETRIC) 
( !  SCOMPARATIVES) 
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Used  in: 
(RU1E305 

Used  in. 
(RULE306 


Used  in: 
(RULE3B7 

Used  in: 
(RULE308 

Used  in: 
(RULE309 

Used  in: 
(RULE310 

Used  in: 
(RULE311 


Used  in: 
(RULE312 

Used  in: 
(RULE313 

Used  in: 


(it  I  STRYA8LE!  ’£  (?P  8  ?E  TC ) > )  > ) } 

((0ERIV14  ;  73)) 

( FUNCTIONALIZE -RULE  USED  l  TIMES) 

•  (7F  ( ?G  ?T ) ) 

->  ((?F  ?G)  ?T) ) 

((0ERIV14  :  84)) 


(DETECT-APPE  *CABII. ITY  HSM- I NSTANT1  ATE  USED  2  TIMES) 

••  ?X  •  (?P  :  ( { ?F  ;  PREDICATE)  8  7ETC) ) 

-> 

(( !  Q*V  HSM) 

WITH  (PROBLEM  :  ?P) 

(OBJECT  :  ?X) 

(CHOICE-SEQ  :  (CHOICE -SEQ-OF  ?X))) 

IF 

(SEXISTS!  (  !  !  ?S  :  SSEQUE MCE  I  ) 

( !  $PARTS<EVENT  ?X) 

(!!  i  SIN!  (.' !  ?C  :  SCHOICE ! )  {!  SPARTSXEVENT  ?S ) ) ) ) 
((DERIV2  :  3)  (OERIi/13  :  1)) 

(CHOICE-SEQ-RULE  USEO  2  TIMES) 

•  (CHOICE-SEQ-OF  (EACH  ’X  ?S  ?£ ) ) 

->  (APPLY  APPEND  (EACH  ?X  73  (CHOICE-SEQ-QF  ?£)))) 

( (DERIV2  :  10)  (0ER1VI3  :  4)) 

( I NTERSECT lON-Sf  ARCH-RULE  CHOICE-SEQ-RULE  USED  1  TIMES) 

•  (CHOICE-SEQ-OF  ?S) 

->  NIL  IF  (NOT  (!  SIN!  (!!  ?E  :  SCHOICE!)  (!  SPARTSCEVFNT  ?S)))) 
( ( OERIV2  :  7)) 


(CHOICE -SFQ-RULE  USED  2  TIMES) 

•  (CHOICE-SEQ-OF  (?C  :  (CHOOSE  &  ?ETC ) ) ) 

->  (LIST  ?C)) 

((OERIV2  .  12)  (OERIV13  :  6)) 

(SIMPl  IFY->NON-CONSrANT-RUl.E  USEO  2  TIMES) 

•  (APPIY  APPEND  (EACH  ?X  ?S  (LIST  IE))) 

->  (EACH  ?X  ?S  ?E  ) ) 

((DFRIV2  :  13)  (DERTV13  :  7)) 


(HSM-INSTANTIATE  USEO  2  TIMES) 


( ?HSM  WITH  ( CHOICE  -SEO  :  (EACH  7X  7INOICES  (CHOOSE  (7F  ?X) 

?S  7 A )  ) ) 


(CHOICES  :  NONE)) 

-> 

(7HSM  WITH  (SEQUENCF  ?F) 

(CHOICES  :  (PROJECT  ?F  7INOICES)) 

(CHOICE-SETS  .  (LAMBOA  (?X)  IS)) 

(INDICES  :  7INOICES) 

(INDEX  :  7X ) 

(VARIABLES  :  NIL) 

(BINDINGS  :  NIL) 

( INITTAL-PATH  :  NIL) 

(COMPLETION-TEST  :  (LAMBDA  (PATH)  (=  (#  PATH)  (4  7IND1CES) ) ) ) ) ) 
{ (OERIV2  :  15)  (0ERIV13  :  9)) 


(CONTROL-RULE  USEO  5  TIMES) 

•  ?E  -> 

(I  SCONSIOER-PROP  ?E  (7P  :  (!  SSELECT  7L ) )  (!  SPROPXVAR  ?E  ?P ) ) 
IF  (SNON-EMPTY!  (71  :  (!  SPROPSvVAR  '£)))) 

((DERIV2  4  23)  (OERIV13  :  2  57  81)) 


(CONTROL-RULE  USED  14  TIMES) 

•  ( 7E  :  (CONSIOER-PROP  ?V) ) 

->  (!  SRETURN-PROP  ?N  ?P  ?V) 

IF  ( SCONS IDERED-PROP!  ?E  ?N  ?P)) 

( (OERIV2  :  14  20  25  58  73  105) 
(OERIV13  :  8  17  27  51  84  71  91  104)) 


(RULE3I4  (HSM-INSTANTIATE  USEO  2  TIMES) 
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(IHSM  WITH  (PROBLEM  :  ?P) 

(CHOICES  :  ?S) 

(  .FORMULATED  PROBLEM  :  NONE)) 

-> 

('  JCONSIOER-PROP  "HSM  REFORMULATED-PROBLEM  (REFORMULATE  IP  ?S) ) ) 
Used  in:  ( (0ERIV2  :  16)  (OrRIVIB  :  10)) 

(RULE315  (FUNCTIONAL -RECURRENCE-RIM  E  USED  2  TIMES) 

•  (REFORMULATE  IE  ?X) 

->  ((LAMBDA  ( ( ?XX  :  (I  Q*V  ?X) ) )  (!  SSUBST  ?XX  IX  ?E)) 

?X) 

IF  (SIMP!  ?X  ?E ) ) 

Used  In:  ((OERIV2  :  19)  (OERIV13  :  15)) 

(RULE316  (HSM- INST ANTIATE  USED  1  TIMES) 

• 

(?HSM  WITH  (REF0RMULATE0-PR08LEN  :  (?P  :  ((LAMBDA  ( ?S )  ?E ) 

’CHOICES) ) ) 

(SEQUENCE  :  ?C ) ) 

->  (’HSM  WITH  (REFORMULATED-PROBLEM  :  (!  ISUBST  IS  ?C  IP))) 

IF  (IINP!  ?C  ?E ) ) 

Used  in:  ( (DERIV2  :  21)) 

(RULE317  ( HSM- INSTANTIATE  USED  2  TIMES) 

• 

( ?HSM  WITH  (REFORMULATED-PROBLEM  :  ((?P  :  (LAMBDA  (?S)  ?E ) ) 

ICHOICES) ) 

(SOLUTION-TEST  :  NONE)) 

-> 

( ?HSM  WI  IH  (PATH  :  ?S) 

(STEP-ORDER  :  NIL) 

(STEP-TEST  :  T) 

(PATH-ORDER  :  NIL) 

(PATH-TEST  :  T) 

(SOLUTION-TEST  :  ?P))) 

Used  in:  ((DFRIV2  :  22)  (DERII/13  :  18)) 

(RULE318  ( HSM- FI X -UP  USEO  1  TIMES) 

•  ( (HSM  WITH  (CHOICE-SETS  :  (LAMBDA  (II)  (SET-OF  IX  ?S  ?P ) ) ) ) 

-> 

(!  ICONS IDFR -  PROP  ?HSM  CHOICE -SETS 

(IAMBOA  (II)  (SET  OF  IX  IS  (POSSIBLE  IP)))) 

--  (USE  IF  ?P  IS  NOT  EVALUABLE)) 

Used  in:  ( (DERIV2  :  26)) 

(RUIE319  ( NECESSARY -CONDITION -RULE  USED  2  TIMES) 

•  (IP  :  ( ( ?F  :  PREDICATE)  &  ?E TC ) ) 

-> 

( !  ICONSIDER-NOTE  ?P 

(■>  ( ?Q  :  (I  IINSTANTIATE  (!  ISEI  ECT  ?L ) ) )  IF  (>>  ?P  ?Q ) ) ) 

IF 

( INON-EMPTY !  ( ?L  : 

(I  ISET-OF  ?R  (1  IPREDICATES) 

(!!  !  ICAN-EXPAND-TO  ?R  IF)))) 

--  (IOOK  FOR  PREDICATE  IR  MENTIONING  IF  (DIRECTLY  OR  INDIRECTLY))) 
Used  in:  ((0ERIV2  :  28  10)) 

(RULE320  (CONTROL -RULE  USED  2  TIMES) 

•  (IE  :  (CONSIDFR-NOTE  ?M) ) 

->  (  !  IRETURN-NOTF.  IN  10  IM) 

IF  (ICONSIDFREO-NOTEI  IE  IN  10)) 

Used  In:  ((0ERIV2  :  39  57)) 

(RULE321  (PURE -TRANSPOSE -RULE  PROPAGATE-SPLIT-RULE  USED  l  TIMES) 

•  (■>  (IP  :  (IF  &  IETC))  (ANO  &  IL ) ) 

->  (ANO  [•>  IP  IQ]  &  [ !  JREMOVE  IQ  IL]) 

IF  (SEXISTS!  IQ  IL  (!!  SINP!  IF  IQ))) 

Used  in:  ( (DERIVE  :  47)) 

(RULE322  (PARHAL -MATCH-RULE  USED  1  TIMES) 

•  (IE  :  (•>  (IF  &  IL)  (FXISTS  IX  IS  (IF  &  IN)))) 
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-> 

( !  {SUFFICE  ?E 
(AND  [IN  ?X  ?S] 

&  [ !  {DISTRIBUTEE  (7X1  ?Y!)  (71  ?M)  (-  ?X1  7Y1)]))) 

Used  in:  ((DERIV2  :  30)) 

(RULE323  (S0LUT1 ON -TEST-> PATH-TEST  USED  5  TIMES) 

* 

(?HSM  WITH  (SOLUTION-TEST  :  ?T) 

(PATH-TEST  :  ?R) 

(PATH  :  ?P) 

(CHOICES  :  ?C)) 

-> 

( !  {CONSIDER -PROP  ?HSM  PATH-TEST 
(AND  ?R 

[LAMflOA  (?P) 

(->  (■)  (!  SSU8ST  ?C  ?P  (?Q  :  (!  {SELECT  ?L  ) ) )  ?Q)  ?Q)])) 

IF 

({NON-EMPTY!  ( ?L  :  (!  {SET-OFP  (!!  ?Q  ;  ( PREDICATE  &  ?£TC))  ?T  T ) ) ) 

( ADO  CONSTRAINT  7Q  FROM  SOLUTION- TEST  TO  PATH-TEST  WHEN  IT  SATISFIES 
MONOTONICITY  CONDITION)) 

Used  In:  ((0FRIV2  :  59)  (OERIVU  :  20  44  65  92)) 

(RULE324  (SPECIAL -CASE-REDUCTION-RULE  USED  l  TIMES) 

•  ( ?E  :  (*  ( ?H  1  ( ( ?F  EXTREME)  7S1))  ( ?H2  :  (?F  ?S2 ) ) ) ) 

->  (!  {TRY  ?E  (SUBSET  ?S2  ?S1)  (IN  Till  7S2 ) ) ) 

Used  in:  ((0ERIV2  :  63)) 

(RULE325  (SPECIAL-CASE -RFOUCT I ON-RUL  E  USED  1  TIMES) 

•  C'E  (■  (7S1  71)  ( ?S2  ?I))) 

( !  {TRY  ?E  (SUBSET  7S2  ?S1)  (IN  ?1  (INDICES-OF  ?S2 ) ) ) ) 

Used  in:  ((0ERIV2  :  66)) 

(RULE326  (TRANSFER-RULE  USEO  t  TIMES) 

•  (IN  (?S  ?!)  ?S) 

-■>  (IN  ?!  (INOICES-OF  ?S ) ) ) 

Used  in:  ((DIK1V2  :  69)) 

(RUIE327  (PATH-TEST-7STEP-TEST  USEO  3  TIMES) 

• 

(?HSM  WITH  (PATH-TEST  :  ?T) 

(STEP-TEST  :  ?S) 

(INDEX  :  71) 

(PATH  :  ?P ) ) 

-> 

(•  {TRY  ?HSM 

(•  ( !  {SF1  ECT  ?L )  (FORAIL  ?I  (INDICES-OF  ?P) 

(TO  :  C  0*v  <))))) 

(THEN  SCONSIDER-PROP  ?HSM  STEP-TEST 
(ANO  ?S 

[1AMB0A  (?I  (?C  :  (1  Q*V  (I  {FILL-IN  "choice  variable")) 

)) 

(THEN  {SUBST  ?C  (?P  ?I)  ?.,]))) 

IF 

({NON  EMPTY!  (’L  :  (!  {SET-OFP  (I!  ?R  :  (PREDICATE  {  7ETC ) )  ?T  T ) )  ) ) 
Used  in:  ((0ERIV2  :  74)  (OERIVU  :  28  72)) 

(RULE323  ( TRANSE ER -RULE  USED  2  TIMES) 

•  ( ( ?Q  QUANTIFIER  PREDICATE)  ?X  'S  ?E ) 

-> 

(?Q  (?I  :  ( !  Q*V  (!  {FILL-IN  "quantifier  variable"))) 

(INOICES-OF  ?S) 

(•  {SUBST  (?S  71)  ?X  ?E ) ) ) 

Used  in;  ((DERIVE  :  80)  (OERIVU  :  73)) 

(RULE329  (PURE -TRANSPOSE -RULE  USEO  5  TIMES) 

•  (?P  :  (PREDICATE  &  7ETC ) ) 

->  ( ?Q  ?X  ’S  ( !  {SUBST  ?E  ?R  ?P ) ) 

IF  ({INP!  (!!  ?R  :  ( ( ?Q  :  QUANTIFIER  PREDICATE) 

?X  ?S  ?E ) )  ?P) 

--  (SUBSUMES  RULE220 ) ) 
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Used  In:  ( (OFRI V2  :  at) 

(DFRIV9  :  32) 

(DERIVIG  :  8  27) 

(OERIV12  :  «)) 

(RULE330  (TRANSFER -RULE  USED  I  TIMES) 

•  l  ?F  :  (fORALL  M  (?S  :  (INOICES-OF  ?L ) )  ?P ) ) 

->  (!  SSUBST  (ROT  (AFTER  7X  71))  TR  7E) 

If  (SIMP!  ( ! !  TR  .  ( IN  ?X  ?S) )  ?P) 

(ASSUMING  7S  IS  A  PREFIX  Of  SEQUENCE  CONTAINING  ?X  --  EG  HSN  PATH)) 
Used  In.  ( (Df RIV2  :  82)) 

(RULE  331  (CONTROL -RUl £  USED  3  TIMES) 

•  (THEN  ?F  &  7L) 

->  ( !  APPLY*  ?F  ?L) 

(THEN  CONSTRUCT  IS  USEO  TO  DELAY  EVALUATION  WHILE  ARGUMENTS  ARE  PUT  IN 
PROPER  FORM)) 

Used  In.  ((OERIV2  :  89)  (DERIV13  :  42  79)) 

(RULE332  (REDUCE-SEARCH-OEPTH  USEO  l  TIMES) 

« 

(THEN  SCONSIDER-PROP 

( ?NSM  WITH  (PATH  :  (PATH) 

(SEQUENCE  .  ’SEQUENCE) 

(INDICES  :  ’INDICES) 

(VARIABLES  :  ?VL) 

(BINDINGS  :  ?8L ) ) 

STEP-TEST  TR ) 

-) 

(THEN  SCONSIDER-PROP 
(?HSM  WITH 

(VARIABLES  : 

((’V  .  (.’  Q'V  <!  $f ILL-IN  "variable  name"))) 

&  7VL ) ) 

(8INOINGS  :  ((’SEQUFNCE  7X)  &  ?BL ) ) 

(INITIAL-PATH  .  (PROJECT  ’SEQUENCE  (PREFIX  ’INDICES  ?X)))) 
STEP-TEST  (I  SSUBST  ’V  (?PATH  ?X)  ?R)) 

If  ( $  I NP  !  (!!  ?PATH  ?X)  ?fl) 

--  (SEARCH  STARUNG  AFTER  ’X  TO  CHOOSE  ?V)) 

Used  in:  ( (Of RIV2  :  93)) 

(RULF333  (HSM-CACHF  USEO  I  TIMES) 

• 

( IMF N  SCONSIDER-PROP 

(?HSM  WITH  (SEQUENCE  :  ’SfQUENCE) 

(BINDINGS  .  ?BL) 

(VARIAIHES  :  ’VI)) 

STEP-TEST  ?R) 

-> 

(THEN  SCONSIDER-PROP 

( THSM  WITH  (BINOINGS  :  ((’E  :  (I  SSELECT  ?L}) 

&  ?BL ) ) 

(VARIABLES  : 

((TV  :  (I  Q*V  (<  Sfru-tN  "variable  name"))) 

*  7Vl))> 

STEP-TEST  ( !  SSUBST  TV  ?E  TR ) ) 

IF 

(SNON-EMPTY!  (?t  : 

(1  SSET-OFP  (11  TE  :  (?f  \  ’ETC)) 

TR  (11  1  SCAN -EXPAND- TO  ?F  ’SEQUENCE))))) 

Used  in:  ((0ERIV2  :  94)) 

(RULE33A  (CONTROL-RULE  USED  5  TIMES) 

*  (THEN  SCONSIDER-PROP  THSM  ’PROP  TV) 

->  (THSM  WITH  (’PROP  :  TV))) 

Used  in:  ( (DERTV2  :  96)  (DERIV13  :  43  58  80  116)) 

(RM.E335  (SOLUTION-IEST-7PAIH-ORDER  USED  1  TIMES)  • 

•  (THSM  WITH  (SOLUTION-TEST  :  (LAMBDA  (7PATH)  (ANO  A  71)))) 

-> 
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( I  JTRY  THSM 

(">  (!  SSUnST  (PREFIX  ’PATH  ANY)  ’PATH  (  'P  (!  JbFLECT  ’L)))  TP) 
(THSM  WITH  (PATH-ORDER  ( L AM80A  (’PAIH)  'P))))) 

Used  in.  ((0ERIV2  :  96)) 

(RULE336  (CHECK-SUFFCOND-RULE  USED  I  TIMES) 

•  ( ?E  .  (•>  ((?P  :  SOFTECTOR! )  ’SI)  (?P  TS2))) 

->  (!  SSUEFTCE  ?E  (SUBSET  ?SI  TS2))) 

Used  tn:  ( (DERIV2  :  97)) 

(RULE337  (OPPORTUNISTIC -EVAl UATION-RULE  USED  t  TIMES) 

•  (SUBSET  (PREFIX  ?S  ?[)  ?S) 

->  T) 

Used  In:  ( (DERIV2  :  9B ) ) 

(RULE338  ( INTRODUCE -SPL FT-RULE  PATH-ORDER - ’STEP-ORDER  USED  I  TIMES) 

(?HSM  WITH  (PATH-ORDER  :  (LAMBDA  (  ’PATH)  ?f» ) ) 

(STEP-TEST  :  (IAMBOA  (?I  ?C)  ?ETC ) ) ) 

-> 

( !  SCONSIDER-PROP  ’H$M  STEP-OROF.R 

(LAMBDA  (?I  ?C)  (!  SSUBST  (APPEND  ’PATH  (LIST  ?C )  )  ’PATH  ?P)))) 
Used  in:  ((0ERIV2  :  tOl ) ) 

(RULE339  (ACTION-RULE  USED  1  TIMES) 

•  (*  (CHOOSE  ?C  ?S  ( ? AC T  7AGENT  ?C))  (TACT  ’AGENT  ’OBJ)) 

->  (»  ?S  (SET  'OBJ)) 

--  ('AGFNT  IS  FORCED  IF  CHOICE  SET  IS  SINGLETON)) 

Used  in:  ((OERIV3  :  7)) 

(RULE340  ( INTRODUCE -SPL I T-RUI  E  USED  2  TIMES) 

•  (■  ’SI  TS2 ) 

->  (AND  [  (  ?R  :  ( !  iORDERINGOF  ?S1)) 

?S1  ?S2]  [7R  ?S2  ’SI]) 

--  (PERMITS  APPLICATION  OF  KNOWLEDGE  ABOUT  TRANSITIVE  RELATIONS)) 
Used  in:  ((OEHIV3  :  12)  (DFRIV13  :  83)) 

( RULE 34 1  (SIMPl IFY-TNON-CONSTANT-RULE  USED  14  TIMES) 

•  ((’R  :  COMM-CONN)  (!  JIOENTITY-OE  ’R)  TP) 

>  ?P) 

Used  in:  ((DFRIV3  :  19) 

(DERIVS  :  9  25  34  43) 

(OERIV6  :  6  28  59) 

(DFRIV9  :  48) 

(DFRIVIO  :  21) 

(DERIVE  1  ;  13) 

(OERIV13  :  21  40  77)) 

(RULE342  (MAKF -ASSUMPTION- RULE  USED  l  TIMES) 

•  (>  (7C  :  SCONSTANT!)  ?E) 

->  ( !  SASSUME  ?E  1C)) 

Used  in:  ( (OERIV3  :  26)) 

(RUIE343  (SIMPLIFY-TNON-CONSTANT-RULE  USEO  8  TIMES) 

•  ((’R  :  COMM-CONN)  IP  (!  SIOENTITY-OF  ?R ) ) 

->  TP) 

Used  in:  ( ( DERIV3  :  36) 

(DFRIV6  :  37  50) 

(DFR1V8  :  13) 

(DFRIV9  :  36  53) 

(DERIVE  4  :  26  78)) 

( RULE344  (INTROOUCE-SPtIT-RUI  F  USED  1  TIMES) 

•  (UNDO  (?P  :  («  ?E  TV))) 

->  (AND  TP  [BECOME  ?E  (!  Q’V  ?E)]) 

--  (?E  MEQ  ’V  BY  DEFINITION  OF  BECOME)) 

Used  in:  ( { OFRIV3  :  49)) 

(RULE348  (USE-ASSUMPTION-RULE  USED  9  TIM'S) 

•  ?E  ->  TV  IF  (JIN!  ,’E  TV)  (!  JASSUMPTIONS ) ) ) 

Used  in:  ({DERIV3  :  62  -  83  :  84) 

(0ERIV4  :  17) 
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(DERIV6  :  SS) 

(DERIV8  :  12) 

(OERIV13  :  47  68  98)) 

(RULE347  (EXAMPLE-RULE  USED  1  TIMES) 

•  ( ?E  :  (EXISTS  ?X  ?S  ?P ) ) 

->  ( !  SSUFFICE  ?E  (!  JSUBST  (!  SSELECT  ?L)  ?X  ?P)) 

IF  (SNON- EMPTY!  (?L  :  (!  SSET-OFP  (!!  7C  .  SCONSTANT!)  7 P  T) ) ) > 

Used  in:  ((OERIV3  :  69)) 

(RULE349  (MAKE-ASSUMPTION-RULE  USED  l  TIMES) 

•  (•>  ?P  ?E) 

->  ( !  SASSUMING  ?P  NIL  T) 

--  (RULE  OUT  CASE)) 

Used  in:  ((OERIV3  :  80)) 

(RULE350  ( R EDUCE ->NEC-CONO- RULE  USEO  1  TIMES) 

•  (ACHIEVE  (ANO  4  ?L ) ) 

->  (ACHIEVE  (ANO  &  [!  SRFMOVE  (!  SSELECT  7L)  ?L])) 

--  (REMOVE  OVER-SPECIFIC  GOAL  CONJUNCT)) 

Used  in:  ((OERIV3  :  81)) 

(RULE351  (USE -ASSUMPTION-RULE  USEO  1  TIMES) 

•  (ACHIEVE  ?P) 

-> 

(ACHIEVE  (ANO  &  [!  SOISTRIBUTE  (!!  TE  ?V )  (!  JASSUMPT IONS )  (■  ?E  ?V)])) 
--  (HACK)) 

Used  in.  ((DERIV3  :  88)) 

(RUIF352  (RFC0GNI2E-RULE  USEO  1  TIMES)  •  (■  ?P  NIL)  ->  (NOT  ?P ) ) 

Used  in:  ( ( DERIV3  :  89)) 

(RULE353  (ACTION-RULE  USED  1  TIMES) 

•  (NOT  (.  ?E  ?P ) ) 

->  (»  ?E  ME) 

(MAKE  VOURSELF  ?E  TO  PREVENT  ?P  FROM  OOING  IT  --  ASSUMING  ?P  NEQ  ME)) 
Used  in:  ((OERIV3  :  91)) 

( RULE354  (USE -ASSUMPTION-RULE  REOUCE-TNEC -CONO-RULE  USEO  2  TIMES) 

•  (?E  :  (ANO  4  71.)) 

->  (!  SSUBST  (I  SSUBST  ?C  TV  ?Q)  ?Q  ?E ) 

IF 

( !  SEXISTS!  ( ! !  TP  :  (•  TV  ?C ) ) 

7L  ( ! !  !  SEXISTS!  (!!  TQ)  (!  SREMOVF  TP  TL)  (!!  !  SINP!  TV  ?Q ) ) ) ) 
Used  in:  ((OERIV3  :  95)  (OERIV5  :  32)) 

(RULE356  (INTRODUCE -SPLIT-RULE  HISTORY-RULE  USEO  1  TIMES) 

•  (TP  :  (AT  .'OBJ  TLOC ) ) 

-> 

(OR  [WAS-OURING  (CURRENT  (7A  :  (!  SSELECT  (I  SACTIONS)))) 

(CAUSE  TP)] 

[BEFORE  (CURRENT  TA)  TP])) 

Used  in.  ( ( 0ERIV4  :  47)) 

(RULE357  (FACT-RULE  USEO  1  TIMES) 

•  (BEFORE  (CURRENT  ROUND- IN-PROGRESS) 

(AT  (?C  :  CARO)  (PILE  TP))) 

->  NIL) 

Used  in:  ( (DERIV4  :  48)) 

(RUIE358  ( RFCOGNT7E -RULE  ACTION-RULE  USEO  3  TIMES) 

•  (CAUSE  (AT  TOBJ  TLOC)) 

->  (MOVE  T08J  (!  Q*V  LOC)  TLOC)) 

Used  In:  ( (DERIV4  .  51)  (DERIVIO  :  8)  (OERIV12  :  91) 

(RULE359  (PURE-TRANSPOSE-RULE  USEO  1  TIMES) 

•  (AND  [UNTIL  TP  TA]  4  TL) 

->  (UNTIL  TP  (ANO  TA  4  TL))) 

Used  in:  ((DERIVS  :  3)) 

(RULE360  (PURF -TRANSPOSE -RULE  PROBLEM-MERGING-RULE  USEO  l  TIMES) 
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•  (AND  &  ?L) 

->  (ACHIEVE  (AND  1  [!  SOTSTRIBUTE  ( 1 1  ACHIEVE  ?P)  ?L  ?P])) 

IF  (NOT  ( 1  SIN!  (!!  -  (ACHIEVE  ?P ) )  ?L ) ) ) 

Used  m:  ( ( DERIV5  :  4)) 

(RULE361  (PROPAGATE-SPLIT-RULE  USED  2  TIMES) 

•  (IN  ?C  (FILTER  ?S  ?P ) ) 

->  (AND  [IN  ?C  ?S]  [?P  ?C])) 

Used  in:  ((DERIV5  :  <.1  41)) 

(RULE362  (SPECIAL-CASE-RFOUCTION-RULE  USED  1  TIMES) 

•  (IE  :  ( ( ?Q  .  QUANTIFIER  PREDICATE) 

?*  ?S  ?P ) ) 

->  (!  STRY  ?E  (SUBSET  ?S  ?SS)  ( ?Q  ?X  ?S  (!  SREMOVE  ?R  ?P))) 

IF  (!  SIN!  ( ! !  ?R  :  (IN  ?X  ?SS ) )  ?P ) ) 

Used  in:  ( (0FRIV6  :  17)) 

(RULE363  (FACT-RULE  USED  t  TIMES) 

•  (SUBSET  (CARDS-PLAYED)  (CAROS)) 

->  T) 

Used  In:  ((DERIV6  :  18)) 

(RULE364  (USE -ASSUMPTION -RULE  EXAMPLE-RULE  USEO  t  TIMES) 

•  ( ?E  :  (IN  (?C  :  SUNBOUNO-VAR! )  (PROJECT  ?F  ?S))) 

-1  (!  STRY  ?E  (IN  ?X  ?S)  (!  SB  I NO  -  VAR  ?C  TV)) 

IF  (SIN!  (!!  ( ?F  ?X)  ?V)  ( !  SASSUMPTIONS) ) ) 

Used  in:  ((OERIV6  :  47)) 

(RULE365  (FACT-RULE  USED  1  TIMES)  •  (IN  (LEADER)  (PLAYERS))  ->  T) 

Used  in:  ( (DERIV6  :  48)) 

( RULE36R  ( TEMPORAL -GOAL -RULE  REDUCE -7NON- EQUIVALENT -RULE  USED  1  TIMES) 

•  (ACHIEVE  ?P) 

->  (ACHIEVE  (!  SSUBST  ?X  ?£  ?P)) 

IF  (SINP!  (!!  ’E  :  (PREVIOUS  ?X))  ?P)) 

Used  in:  ( (DERIV7  :  3)) 

(RULE367  (RELOGNI2E-RUIE  USED  1  TIMES) 

•  (NOT  (?P  ?X ) ) 

->  (( !  SOPPOSITE-1F  ?P)  ?X ) ) 

Used  in:  ( (DERIV7  :  8)) 

(RULE368  ( RFCOGN IZE -RULE  ACTION-RULE  USED  2  TIMES) 

•  (UNOO  (AT  ?OOJ  7LQC ) ) 

->  (MOVE  ?OBJ  ?LOC  ( !  Q*V  LOC) ) ) 

Used  in:  ((0FRIV8  :  10)  (DERTVIO  :  29)) 

(RULE369  ( RFOUCE ->NEC -COND-RUi  E  USED  1  TIMES) 

•  ( IN  ?C  (SET-OF  ?X  ?S  ?P) ) 

->  ( !  SSUBST  ?C  'X  ?P) 

--  (LIKE  RULE  10  BUT  ASSUME  (IN  ?C  ?S))) 

Used  in:  ( (DERIV9  :  30)) 

(RULE370  (INTRODUCE-SPLIT-RULE  HISTORY-RULt  USED  1  TIMES) 

•  ( ? E  :  (*  (SET-OF  'X  ?S  ?P ) ) ) 

-> 

( !  STRY  ?E 

(NOT  (DURING  (!  SINSTANTIATE  ( ?A  :  (!  SSELECT  (!  SACTTONS)))) 
(CAUSE  ?P))) 

(-  (*  (SET-OF  ?X  'S  (BFFORF  (CURRENT  ?A)  ?P ) > ) 

(#  (SET-OF  ?X  IS  (WAS-OURING  (CURRENT  ?A)  (UNDO  7P ) ) ) ) ) ) 

--  (OASIS  FOR  CACIIE-ANO-UPOATE  SCHFME  ) ) 

Used  in:  ((DERIVIO  :  4)) 

(RULE371  (PURE-TRANSPOSE-RULE  PROPAGATE-SPLIT-RULE  USED  2  TIMES) 

•  (BEFORE  ’A  (?P  &  7!  )) 

->  (?P  &  (1  SD1STRIBUTE  7X  ?L  (BEFORE  ? A  ?*)))) 

Used  in:  ((DERIVIO  :  15  -  16)) 

(RULE372  (FACT-RULE  USED  1  TIMES) 

•  (BEFORE  (CURRENT  ROUND- IN-PROGRESS )  (IN-POT  7C ) ) 

->  NIL) 
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Used  in; 

(RULE373 
Used  in: 

(RULE374 

Used  in: 
(RULE375 

Used  in: 

(RULE376 
Used  in: 

(RULE377 

Used  in: 
(RULE373 


Used  in: 
(RULF379 

Used  in. 
(RULE380 

Used  in: 
(RULE381 

Used  in: 
(RULE382 

Used  in: 
(RULE383 

Used  in: 
(RULE384 


Used  in: 


((OERIVIO  :  17)) 

(FACT -RULE  USED  1  TIMES)  •  (AT  7C  HOLE)  ->  NIL) 

((OERIVIO  :  19)) 

(HFURIST1C-EQUIVALENCE-PRESERVING-RULE  USED  1  TIMES) 

•  (BEFORE  ?A  (? P  .  BOOLEAN  SCONSTANT1)) 

•>  ?P) 

((OERIVIO  :  20)) 

(PROPAGATE-SPLIT-RULE  USED  1  TIMES) 

•  ( R  (SET-OF  ?X  'S  (NOT  ?P) ) ) 

->  (-  (d  ?S)  (d  (SET-OF  7X  ?S  ?P) ) ) ) 

((OERIVIO  :  23)) 

(FACT-RULE  USED  1  TIMES)  •  (d  (CAROS-IN-SUIT  ?S))  ->  13) 

((OERIVIO  :  24)) 

(RECOGNIZE-RULE  USED  1  TIMES) 

•  (UNOO  (NOT  ?P ) ) 

->  (CAUSE  ?P)) 

( (OFRIV12  :  3)) 

(SOI  UT10M-rEST->C0MPl ET10N-TEST  USED  1  TIMES) 

•  ( ?HSM  WITH  (SOLUTION-TEST  :  (LAMBOA  (?S)  (ANO  S,  ?L)))) 

-> 

( ?HSM  WITH  (COMPI  FTION-TEST  :  (LAMBOA  (?S)  ?P ) ) 

(SOLUTION-TEST  :  (LAM80A  (?S)  (ANO  i  [!  SREMOVE  ?P  ?L])))) 
rf  (SEXISTS!  ?P  71  (!!  !  JINP!  (!!  d  ?S)  ?P)J 
--  (VP  SHOULD  NOT  DEPEND  OTHERWISE  ON  ?S) 

(MOVE  CONSTRAINT  ON  SOLUTION  LENGTH  TO  COMPLETION  TEST)) 

( (OERIV13  :  19)) 

(PARTIAL -MATCH-RULE  USED  2  TIMES) 

(?E  : 

(•>  (FORALL  ?X  ?S l  ?P)  (FORALL  ?V  7S2  (!  ITFST-SUBST  ?V  ?X  ?P ) ) ) ) 
-»  (.'  ISUFFICE  ?E  (SUBSET  ?S2  7S1))) 

((DERIV13  :  22  67)) 

(PARTIALMATCH-RULE  USED  l  TIMES) 

•  (>  (FORALL  ?X  'SI  ?P)  (FORALL  ?Y  7S2  ?Q)) 

->  (•  ?Q  (Oft  [!  SSUBST  ?Y  ?X  ?P]  [IN  ?Y  (OIFF  ?S2  ?SI)])) 

--  (ASSUMING  (SUBSET  ?S1  ?S2 ) ) ) 

((DFRIV13  :  3L)) 

(EiABORATE-RULE  USED  1  TIMES) 

•  (INDICES-OF  7S) 

->  (IB: UB  l  (d  ?S) ) 

--  (ASSUMING  ?S  INDEXEO  BY  INTEGER)) 

( ( DER IV 13  :  32)) 

(RECOGNIZE-RULE  USED  l  TIMES) 

•  (OIFF  (LB:U8  ?Ll  ?U)  (LB:UB  ?L2  ?U) ) 

->  (LB : UB  7LL  (-  ?L2  1)) 

—  (SIMILAR  TO  RULE2S2)) 

((0ERIV13  :  33)) 

(CHECK-SUFF-CONO-RULE  USED  2  TIMES) 

•  ( ?E  :  (■>  ( ( ?R  :  TRANSITIVE)  7X  7Z)  ( ?R  7Y  72))) 

->  (1  SSUFFTCE  ?E  (?R  ?Y  ?X ) ) ) 

((DFRIV13  :  45  93)) 

(STEP- TEST -7GENFRAT0R  USED  1  TIMES) 

( 7HSM  WITH  (CHOICE-SETS  :  ( I.AM8DA  (?I)  7S) ) 

(STEP-TEST  :  (LAMBOA  (71  7C)  ?T))) 

-> 

(THEN  SCONSIOER-PROP  (7HSM  WITH  (STEP-TEST  :  T)) 

CHOICE-SETS  (LAMBDA  (71)  (SET-OF  ?C  7S  ?T) ) ) 

--  (INCORPORATE  TEST  INTO  GENERATOR)) 

( (DERIV13  :  52)) 


♦ 


I 


( 
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(RUIE385  (INTRODUCE-SPLIT-RULE  USED  1  TIMES) 

•  (SET-OE  ?X  ?S  (OR  4  ?L ) ) 

->  (IF  ?P  ?S  ( SET -OF  ?X  ?S  (OR  4  [!  SR E MOVE  ?P  ?L  ]  ) ) ) 

IF  (SEXISTS!  ?P  ?L  (!!  !  ilNOEPENDENT -Of  ?P  ?X ) ) ) 

Used  in:  ((DERIV13  :  53)) 

(RULE386  (GENERATORS PRECOMPUTE  USED  1  TIMES) 

(THEN  SCONSIOER-PROP  (?HSM  WITH  (PATH  ■  7PATH ) )  CHOICE-SETS  ?CS) 

-> 

(THEN  SCONSIOER-PROP  ?HSM  CHOICE-SETS 
( !  SSU8ST 

((!  SDEFINE  ( ?F  :  (!  SFILL-IN  "Function  name")) 

((?Y  :  (!  Q<V  ?X ) ) ) 

(!  SSUBST  ?Y  (?C  :  (!  SSELECT  ?L ) )  ?FS)) 

?C) 

?FS  ?CS) ) 

IF 

(SEXISTSP!  (!!  ?FS  :  (SET-OF  ?X  ?S  ?P) ) 

?CS 

(!!  !  SMON-EMPTY! 

(’L  .  ( !  SSET-OFP  (!!  ?C)  ?P  (!!  !  SIMP!  7PATH  ?C))))) 

(FUNCTION  ?F  CAN  fl£  PRECOMPUTED  IF  ?S  IS  SMALL  AND  7FS  DEPENDS  ON  7PATH 
ONLY  THROUGH  ?C )  ) 

Used  in:  { (DERIV13  :  55)) 

(RULE387  (RECOGNIZE-RULF  USED  1  TIMES) 

•  (>■  ( ¥  (SET-OF  ?X  ?S  ?P ) )  l) 

->  (EXISTS  ?X  ?S  ?P) 

--  (CONVERSE  OF  RULF291 ) ) 

Used  in:  ( (OERIV13  :  85)) 

(RULE388  (PARTIAL-MATCH-RULE  USEO  1  TIMES) 

• 

(?E  : 

(SUBSET  (SET-OF  ?X  7SI  ?P) 

(SET-OF  ?Y  7S2  (!  STEST-SU8ST  ?Y  7X  ?P)))) 

->  ( !  SSUFFICE  ?E  (SUBSET  ?S1  ?S2 ) ) 

--  (LIKE  RULE30  WITH  (?F  ?S)  •  (SET-OF  ?X  ?S  ?P ) ) 

( NOTF  SIMILARITY  TO  RULE379)) 

Used  in:  ((DFRIV13  :  97)) 

(RULE389  ( INTROOUCE-SPLIT-RIJLE  PATH-TEST-XSTEP-TEST  USED  1  TIMES) 

• 

(?HSM  WITH  (PATH-TEST  :  ?PT) 

(PATH  :  ?PATH ) 

(STEP-TEST  :  (IAMBDA  (?I  ?C)  ?ST))) 

-> 

(THEN  SCONSIOER-PROP  'HSM  STEP-TEST 
(LAMBDA  (?I  7C ) 

(AND  ?ST 

[!  SSUBST  (APPENO  ’PATH  (LIST  ?C ) )  ’PATH  (!  SSELECT  ?L)]))) 
IF  (SNON-EMPTY!  (?L  :  (!  SSET-OFP  (!!  PREDICATE  &  ?ETC)  ?PT  T))) 

--  (SIMILAR  TO  RULE338) ) 

Used  in:  ((OERIV13  :  105)) 

( RULE390  (STMPt  IFY-BY- INDUCTION  USED  1  TIMES) 

• 

(?E  : 

(THEN  SCONSIDER-PROP  (?HSM  WTTH  (PATH-TEST  :  ?PT) 

(PATH  :  ?PATH )  ) 

STEP-CONSTRAINT  7ST) ) 

->  ( !  SSUBST  T  ?P  ?E ) 

IF 

( SI N I  (LAMBDA  (’PATH) 

(?P  :  ( !  SSELECT  (.»  SSET-OFP  (!|  PREDICATE  4  ?ETC)  ?ST  T)))) 

?PT) 

--  (?P  IS  TRUE  FOR  EXISTING  PATH  BY  INDUCTION)) 

Used  in:  ( (DERIVI3  ;  108)) 
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(RULE391  (RECOGNIZE "RULE  USED  1  TIMES) 

•  (IF  ?P  ?X  T) 

->  (OR  [MOT  ?P]  ?X) 

--  (SIMILAR  TO  RULE294)) 

Used  in:  ((0ERIV13  :  109)) 

(RULE392  (RECOGMIZE-RULE  USED  I  TIMES) 

•  (•<  (?£  :  SNON-NEGATIVE!)  0) 

->  (■  re  o)) 

Used  in:  ( (DERIV13  :  111)) 

(RULE393  (PROPAGATE-SPLIT-RULE  FUNCTIOMALIZE-RULE  USED  2  TIMES) 

•  (LAMBDA  (?I)  (?F  1  ?L ) ) 

->  ( ?F  &  ( !  SOISTRIBUTE  (!!  ?X)  ?L  (!)  (LAMBDA  (?1)  ?X)))) 
--  (TREAT  ?F  AS  FUMCTIOMAL)) 

Used  in:  ( (DERIV14  :  13  16)) 

NIL 

<90>recordf lie 

RECORD  FILE  OSK;  (RUL319  .  QZG)  CLOSED  20  MAR-81  18:35:08 
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Appendix  C 
Conceptual  Knowledge 

This  appendix  includes  FOO’s  is-a  hierarchy  (§C.l)  and  semantic  relations  (§C.2),  and  lists  the 
definitions  of  concepts  used  in  task  descriptions  and  advice  (§C.3). 


C.l.  Is-a  Hierarchy 

FOO’s  is-a  hierarchy  provides  connections  between  general  concepts  used  in  transformation  rules 
and  specific  concepts  used  in  task  advice.  The  hierarchy  is  tangled:  a  concept  may  have  more  than 
one  immediate  generalization.  For  example.  NON-NEGATIVE-INTEGER  is  both  NON-NEGATIVE  and 
an  INTEGER. 

The  semantics  of  the  “is-a”  relationship  arc  deliberately  left  vague.  Roughly  speaking,  the  non¬ 
terminal  nodes  represent  concept  features  (e.g.,  REFLEXIVE.  HEARTS),  and  the  is-a  hierarchy  marks 
concepts  in  such  a  way  that  a  concept  with  a  given  marking,  e.g,  REFLEXIVE,  inherits  more 
generalized  markings,  e.g.,  PREDICATE,  FUNCTION.  Each  feature  can  be  viewed  as  implicitly 
specifying  a  particular  “is-a”  relationship;  for  example,  the  marking  HEARTS  on  the  concept  PLAY  can 
be  interpreted  as  meaning  “PLAY  is-a  concept  relevant  to  the  domain  of  HEARTS. 

The  is-a  hierarchy  includes  both  constants  and  functions.  FOO  has  definitions,  listed  in  Appendix 
C.3,  for  some  of  the  concepts,  e.g.,  PLAY,  but  not  for  others,  e.g.,  DURING. 
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RECORD  FILE  OSK :  (ISA319  .  QZG)  OPENED  20-MAR-81  18:15:09 
<70>p-f  any-concept 

ANY-CONCEPT: 

AFFECT:  (CAUSE  UNDOES) 

CHANGE:  (CAUSE  REMOVE- 1- FROM  UNOO) 

BOOLEAN:  T 
NIL:  0 
CARD:  QS 
COLLECTION: 

LIST:  SET 
COMM-CONN: 

CONJ:  (AND  D*  INTERSECT) 

JOIN:  (APPEND  SCENARIO) 

DISJ:  (♦  0+  OR  UNION) 

COMPUTABLE:  (♦  -  ANO  NEQ  NOT  OR) 

OEPENOENCE-OP:  (0*  D+  D- ) 

CONSTANT:  (1  T) 

NIL:  0 

CONSTRUCTED:  CANTUS 

FILTERED:  FORALL 

EXISTENTIAL:  (SET-OF  THE) 

EXISTS:  EXISTS-UNIQUE 
FORMULA:  PR-OISJOINT-FORMULA 
FUNCTION: 

FXTRFME:  (HIGHEST  HIGHEST  -  IN -SU I T -LED  LOWEST) 

HOMOMORPHISM:  ( ^OCCURRENCES  CHO ICE -SEQ-OF  OURING  HAVE-POINTS  IN  SET-OF) 
INJECTIVE:  (CARO-OF  EACH  PLAY  PLAY-CARD  TAKE) 

DISTRIBUTE:  EACH 

PREDICATE:  (AT  BREAKING-SUIT  CAN  DISJOINT  EXTENO-TONE  FLUSH  FOtlOWING  FORALL  HAS 

HAS-ME  HAVE-POINTS  IN  IN-POT  IRREVERSI BLE -DURI NG  LEAD- SAFE -SPADE 
LEAD-SPADE  LEAD-TO  LEADING  LEGAl  LEGAL -CANTUS !  LOW  MUST  NON-VOID 
OUT  OVERLAP  PLAY-SPAOE  POSSIBLE  QS-OUT  ROUND- IN-PROGRESS 
SAFE-SPAOE!  SPADE!  SPLIT  TAKEN  TRICK -HAS- POI NTS  TRICK- IN-PROGRESS 
UNCHANGEABLE  UNOOABLE  OUR  I NG  USABLE-INTERVAL!  VOID) 

ACTION:  (DEAL  EXTEND  MOVE  PLAY  PLAY-CARD  ROUND- IN-PROGRESS  TAKE  TAKE-TRICK 

TRICK) 

ANTI-SYMMETRIC:  (HIGHER  LOWER) 

BOOLEAN-OP:  (•>  AND  NOT  OR) 

EXISTS:  EXISTS-UNIQUE 
REFLEXIVE:  (■>  DURING  SUBSET) 

EQUIVALENCE:  • 

TRANSITIVE:  (*>  SUBSET) 

COMPARATIVE:  (*<  >»  HIGHER  LOWER) 

EQUIVALENCE:  ■ 

QUANTIFIER:  (CHOOSE  EACH  FOR-SOME  FORALL  SET-OF  THE) 

DISTRIBUTE:  EACH 
EXISTS:  EXISTS-UNIQUE 

SET-FUNCTION:  (CAROS  CARDS- IN-HAND  PROJECT  SET  SET-OF) 

DISTRIBUTE:  EACH 

HEARTS:  (DEAL  PLAY  PLAY-CARD  ROUNO- IN-PROGRESS  TAKE  TAKE-TRICK  TRICK) 

INCR1:  ACHOOSE 

INCR1-0ECR2:  (-  //) 

MAPPED:  (CHOOSE  EACH  FOR-SOME) 

DISTRIBUTE:  EACH 
MUSIC:  EXTEND 
NUMBER: 

INTEGER: 

NON-NEGATIVE-INTEGER:  (0  1  0) 

NON-NEGATIVE: 

NON-NEGATIVE-INTEGER:  (0  1  0) 

NUMERICAL:  (•  ■<  >-) 

ONE -OF: 

EXTREME:  (HIGHEST  HIGHEST-IN-SUIT-LEO  LOWEST) 

SEQUENCE:  CANTUS 

STEP-CONSTRAINT:  (STEP-ORDER  STEP-TEST) 

UNTYPED:  (CHOOSE  EACH  SET-OF  THE  WHILE) 

DISTRIBUTE:  EACH 
<71  XrecordM  le 

RECORD  FILE  DSK :  (ISA319  .  QZG)  CLOSED  20-MAR-8t  18:22:31 
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C.2.  Semantic  Relations 


Semantic  relationships  among  concepts  in  foo  are  represented  as  triples  of  the  form 
<attribute>  of  <object>  Is  <value>: 

RECORD  FILE  OSK.  (SEM319  .  QZG)  OPENEO  19-MAR-81  21:47:17 
NIL 

<98>p-relations 


ADD  of  ^OCCURRENCES  is  ♦ 

ADO  of  CHOICE-SEQ-OF  is  APPEND 

ADD  of  DURING  is  OR 

ADD  of  HAVE-POINTS  is  OR 

ADD  of  IN  is  OR 

ADO  of  SET-OF  is  UNION 

COMPARATIVE  of  HIGHEST  is  HIGHER 
COMPARATIVE  of  LOWEST  is  LOWER 

IDENTITY  of  ♦  is  0 
IDENTITY  of  AND  is  T 
IDENTITY  of  O*  is  INCREASING 

OPPOSITE  of  •<  is  >* 

OPPOSITE  of  >•  is  ■< 

OPPOSITE  of  HIGH  is  LOW 
OPPOSITE  of  HIGHER  is  LOWER 
OPPOSITE  of  LOW  is  HIGH 
OPPOSITE  of  LOWER  is  HIGHER 

PREDICATE  of  HIGHER  is  HIGH 
PREDICATE  of  LOWER  is  LOW 

SUPERLATIVE  of  HIGHER  is  HIGHEST 
SUPERLATIVE  of  LOWER  is  LOWEST 

NIL 

<99>recordf  ile 

RECORD  FILE  OSK:  (SEM319  QZG )  CLOSED  19-MAR-81  21:47:30 
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C.3.  Concept  Definitions 

Concept  definitions  are  represented  in  FOO  as  LISP  function  definitions.  The  somewhat  awkward 
construct  (?x  :  ( !  Q*V  X))  is  used  to  generate  a  unique  variable  name  each  time  the  definition 
containing  it  is  instantiated,  so  as  to  prevent  name  conflicts  in  expressions  with  nested  quantifiers. 
The  generated  name  consists  of  x  followed  by  a  number:  x  l,  X2 . 

RECORD  FILE  OSK:  (0EF319  .  QZG)  OPENED  19-MAR-81  23:23:34 
NIL 

<60)(length  d«f Ined-Tnj) 

112 

<61>p-def Inltlons 

(DE  4CARDS-IN-HAN0  (P)  (0  (CAROS- IN-HANO  P) ) ) 

(OE  PCAROS -OUT  NIL  (0  (CAROSOUT) ) ) 

(OE  ACARDS -OUT -IN-SUIT  (SUIT)  (0  (CAROS-OUT-IN-SUIT  SUIT))) 

(DE  ^OCCURRENCES  (N  C)  (0  (SET-OF  ( ?X  :  (!  Q*V  X))  C  (■  ?X  N) ) ) ) 

(OE  AT  (C  W)  (-  (LOC  C)  W) ) 

(DE  AVOID  (E  S)  (ACHIEVE  (NOT  (DURING  S  E ) ) ) ) 

(DE  AVOIO-TAKING-POINTS  (TRICK)  (AVOID  (TAKE-POINTS  ME)  TRICK)) 

(OE  BECOME  (F  C) 

(LAMBDA  (I)  (AND  [NOT  (-  (F  I)  (C  I))]  [■  (F  (<■  I  1))  (C  I)]))) 

(DE  BREAK-SUIT  (P) 

(WHILE  (NOT  (IN-SUIT  (CARO-OF  P)  (SUIT-LED) ) )  (PLAY-CARD  P) ) ) 

(DE  BREAKING-SUIT  (P)  (NOT  (IN-SUIT  (CARO-OF  P)  ( SUIT -LED) )) ) 

(DE  CAN  (A)  (EXISTS  (?X  :  (!  Q*V  A))  (ACTIONS)  (A  ?X))) 

(DE  CANTUS  NIL 

(EACH  (?I  :  (I  Q*V  I)) 

(LBUB  t  (CANTUS-LENGTH)) 

(CHOOSE-NOTE  II))) 

(DE  CANTUS!  (C)  (EACH  I  (LB:U8  l  (0  C) )  (NOTE  I  I))) 

(OE  CANTUS  - 1  (J)  (PREFIX  CANTUS  J)) 

(OE  CARO-OF  (P) 

(THE  (?C  :  (!  Q*V  C)) 

(CARDS-PLAYED) 

(DURING  (CURRENT  TRICK)  (PLAY  P  ?C)))) 

(OE  CAROS- IN-HANO  (P)  (SET-OF  (?C  :  (!  Q«V  C ) )  (CARDS)  (HAS  P  TC ) > ) 

(DE  CAROS- IN-POT  NIL  (SET-OF  (?C  :  (I  Q*V  C ) )  (CAROS)  (AT  ?C  POT))) 

(DE  CAROS- IN-SUIT  (SUIT) 

(SET-OF  ( ?C  :  (!  Q«V  C))  (CARDS)  (IN-SUIT  ?C  SUIT))) 

(DE  CAROS- IN-SUIT -LED  (S)  (FILTER  S  IN-SUIT-LED)) 

(DE  CAROS-OUT  NIL  (FILTER  (CAROS)  OUT)) 

(OE  CAROS-OUT-IN-SUIT  (SUIT)  (FILTER  (CARDS-1V-SUIT  SUIT)  OUT)) 

(OE  CAROS -PLAYED  NIL  (PROJECT  CARO-OF  (PLAYERS))) 
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(DE  CAUSE  (P)  ( LAMBDA  (I)  (AND  [NOT  (P  1)]  [P  (t  I  1)]))) 

(01  CHOOSE-NOTE  (I)  (CHOOSE  (NOTE  I)  (TONES)  (NOTE  I))) 

(0£  CLIMAX  (C)  (HIGHEST  C) ) 

(OE  DEAL  (C  P)  (GET-CARO  P  C  OECK)) 

(DE  DISJOINT  (SI  S2)  (NOT  (OVERLAP  SI  SZ ) ) ) 

(DE  EXCEPT  (C  S)  (SET-OF  (?X  :  (!  Q*V  X))  S  (NOT  (■  ?X  C ) ) ) ) 

(OE  EXISTS-UNIQUE  (X  S  P)  (*  (A  (SET-OF  X  S  P) )  t)) 

(DE  EXTEND  (E  S)  (BECOME  S  (APPEND  S  (LIST  E) ) ) ) 

(OE  EXTEND-TONE  (N  C) 

(AND  [EXTEND  (?X  :  (!  Q*V  X))  C]  [-  (TONE-OF  ?X)  N])) 

(OE  FILTER  (S  P)  (SET-OF  (?X  :  (1  Q’V  X))  S  (P  ?X))) 

(OE  FLUSH  (C)  (MUST  (OVNER-OF  C)  (PLAY  (OWNER-OF  C)  C))) 

(OE  FOLLOWING  (P)  (NOT  (LEADING  P))) 

(OE  GET-CARO  (P  C  S)  (MOVE  C  S  (HAND  P))) 

(OE  HANOS  (S)  (PROJECT  HAND  S)) 

(OE  HAS  (P  C)  (AT  C  (HAND  P))) 

(DE  HAS-ME  (C)  (HAS  ME  C> ) 

(DE  MAS-POINTS  (C)  (>  (POINTS  C)  0)) 

(DE  HAVE-POINTS  (S)  (EXISTS  (?C  :  (!  Q*V  C))  S  (HAS-POINTS  ?C ) ) ) 

(OE  HEART!  (C)  (•  (SUIT-OF  C)  H) ) 

(OE  HIGHEST  (S) 

(THE  (?C  :  ( !  Q*V  C) ) 

S  (FORALL  ( ?X  :  (!  Q*V  X))  S  (NOT  (HIGHER  ?X  ?C ) ) ) ) ) 

(OE  HIGHEST-IN-SUIT-LED  (S)  (HIGHEST  (CAROS- IN-SUIT-LED  S) ) ) 

(DE  IN-POT  (C)  (AT  C  POT)) 

(OE  IN-SUIT  (C  SUIT)  (■  (SUIT-OF  C)  SUIT)) 

(OE  IN-SUIT-LEO  (C)  (■  (SUIT-OF  C)  (SUIT-LED))) 

(DE  INTERVALS -OF  (S) 

(DISTRIBUTE  (?I  :  (1  Q*V  I)) 

(LB:UB  2  (#  S)) 

(INTERVAL  (S  (-  ?I  1))  (S  ?!)))) 

(DE  IRREVERSIBLE -OUR ING  (S  P)  (NOT  (UNOOABLE -DURING  S  P) ) ) 

(OE  LB :UB  (LB  UB) 

(SET-OF  (?K  :  (!  Q*V  K ) )  (INTEGERS)  (BETWEEN  ?K  LB  UB))) 

(OE  LEAD  (P  C)  (WHILE  (LEAOING  P)  (PLAY  P  C) ) > 

(OE  LEAO-CARO  (P)  (WHILE  (LEADING  P)  (PLAY-CARD  P))) 

(DE  LEAO-SAFE-SPADE  (P) 

(ANO  [LEAOING  P]  [SPAOE!  (CARO-OF  P) ]  [HIGHER  QS  (CARO-OF  P)])) 
(OE  LEAO-SPAOE  (P)  (ANO  (LEAOING  P]  [SPAOE!  (CARO-OF  P)])) 

(DE  LEAO-TO  (EVENT!  EVENT2  TIME) 
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(•>  (DURING  TIME  EVENT1)  (OURING  TIME  EVENT2 ) ) ) 

(DE  LEADER  NIL  (PREVIOUS  (TRICK-WINNER))) 

(OE  LEADING  (?P)  (•  (LEADER)  ?P)) 

(DE  LEGAL  (P  C) 

(ANO  [HAS  P  C] 

[■>  ( LEADING  P)  (OR  [CAN-LEAD-HEARTS  P]  [N£Q  (SUIT-OF  C)  H])] 
[•>  (FOLLOWING  P) 

(OR  [VOID  P  (SUIT-LED)]  [IN-SUIT  C  (SUIT-LED)])])) 

(OE  LEGAL -CANTUS!  (S) 

(AND  [IN  (#  S)  ( LB : UB  8  16)] 

[FORAIL  (?I  :  (!  Q*V  INTERVAL)) 

(INTERVALS-OF  S) 

(USABLE -INTERVAL I  ?I)] 

[SUBSET  (MELODIC-RANGE  S)  (MAJOR  10)] 

[«  (POCCURRENCES  (CLIMAX  S)  S)  1])) 

(DE  LEGALCARDS  (P)  (SET-OF  (?C  :  ( '.  Q*V  C))  (CARDS)  (LEGAL  P  ?C))) 

(DE  LOWEST  (S) 

(THE  (?C  :  (!  Q«V  C)) 

S  (FORALL  (?X  :  (!  Q*V  X))  S  (NOT  (LOWER  ?C  ?X ) )  > ) ) 

(DE  MELODIC-RANGE  (M)  (SIZE  (INTERVAL  (LOWEST  M)  (HIGHEST  M)))) 

(OE  MOVE  (OBJ  SOURCE  DEST) 

(ANO  [*  (LOC  OBJ)  SOURCE]  [BECOME  (LOC  OBJ)  BEST])) 

(DE  MUST  (AGT  ACT)  (•  (ACTIONS-OF  AGT)  ACT)) 

(OE  NEXT  (E)  (LAMBOA  (J)  (E  (*  J  1)))) 

(OE  NEXT-LEADER  NIL  (TRICK-WINNER)) 

(OE  NEXT-NOTE  NIL  (CHOOSE  ( ?N  :  (I  Q*V))  ( TOHCS )  ?N)J 

(OE  NON-VOID  (P)  (NOT  (VOID  P  (SUIT-LED)))) 

(OE  NOTE  (I)  (NTH  CANTUS  I)) 

(OE  NOTE!  (I)  (LAMBOA  (N)  (*  N  (NOTE  I)))) 

(OE  OCCURS-ONCE-BY!  (TONE  I) 

(■  (^OCCURRENCES  TONE  (PREFIX  CANTUS  I))  I)) 

(OE  OPPONENTS  (P)  (OTFF  (PLAYERS)  (SET  P))) 

(OE  OUT  (C)  (EXISTS  (?P  :  (!  Q*V  P))  (OPPONENTS  ME)  (HAS  ?P  C) ) ) 

(OE  OVERLAP  (SI  SZ )  (EXISTS  <?X  :  (!  Q*V  X))  SI  (IN  ?X  SZ ) ) ) 

(OE  OWNER-OF  (C)  (THE  P  (PLAYERS)  (HAS  PC))) 

(DE  PASS  (PL  C  P2)  (GET-CARD  P2  C  (HAND  PI))) 

(DE  PILES  (S)  (PROJECT  PILE  S)) 

(OE  PLAY  (P  C)  (MOVE  C  (HAND  P)  POT)) 

(OE  PLAY-CARD  (P) 

(CHOOSE  (CARD-OF  P)  (LEGALCARDS  P)  (PLAY  P  (CARO-OF  P)))) 

(DE  PLAY-SPAOE  (P)  (ANO  [PLAY  P  (?C  :  (!  Q*V  C))]  [IN-SUIT  TC  S] ) ) 

[OE  PLAY-SUIT  (P  SUIT) 

(ANO  [PLAY  P  (7C  :  (I  Q’V  C))]  [IN-SUIT  ?C  SUIT])] 

[0E  PLAYER-OF  (C) 

(THE  (?P  :  (!  Q*V  P))  (PLAYERS)  (•  (CARO-OF  ?P)  C))] 
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(OE  POINT -CAROS  NIL 

(SET-OF  (?C  :  (I  Q'V  C) )  (CARDS)  (NAS'POINTS  ?C))) 

(DE  POINTS  (C) 

(IF  (■  C  QS)  13  (IF  (HEARTl  C)  1  (IF  (•  C  JO)  -10  0)))) 

(OE  PR-OISJOINT  (H  S  U)  (PR-0ISJ01NT-F0RMULA  (»  H)  (*  S)  {#  U) ) ) 

(OE  PR-OISJOINT-FORMOLA  (*H  #S  #0) 

(//  (ACHOOSE  (-  #U  NS)  AH)  (NCHOOSE  AU  AH))) 

(OE  PROJECT  (F  S)  (EACH  ( ?X  :  (I  Q*V  *))  S  (F  ?X  > ) ) 

(OE  QS-OUT  NIL  (OUT  QS)) 

(DE  QSO  NIL  (OWNER-OF  QS)) 

(OE  ROUNO- IN-PROGRESS  NIL  (EACH  I  ( TRICK- INDICES)  (TRICK))) 

(OE  ROUNO-PROGRESSING  NIL  T) 

(OE  SAFE -SPADE !  (C)  (AND  [SPADE!  C]  [LOWER  C  QS])) 

[OE  SPADE!  (C)  (IN-SUIT  C  S)] 

(DE  SPADES  -  IN  (L)  (SET-OF  (?C  :  (!  Q*V  C))  L  (»  (SUIT-OF  ?C)  S) ) ) 

(DE  SPLIT  (B  P)  (OR  [AND  B  [•>  B  P]]  [AND  [NOT  B]  [«>  (NOT  8)  P]])) 

(OE  SUIT-LED  NIL  (SUIT-OF  (CARO-OF  (LEADER)))) 

(OE  TAKE  (P  C)  (HOVE  C  POT  (PILE  P))) 

(DE  TAKE-POINTS  (P) 

(FOR-SOME  (TC  :  (!  Q'V  C ) )  (POINT-CARDS)  (TAKE  P  TC))) 

(OE  TAKE-TRICK  (P) 

(EACH  ( 7C  :  (!  Q'V  C ) )  (CARDS -PLAYED)  (TAKE  P  ?C))) 

(DE  TAKEN  (C)  (EXISTS  P  (PLAYERS)  (TOOK  P  C))) 

(DE  TONES-OF  (C)  (PROJECT  TONE-OF  C)) 

(DE  TOOK  (P  C)  (WAS-OURING  (CURRENT  ROUNO- IN-PROGRESS )  (TAKE  P  C) ) ) 

(OE  TRICK  NIL 

(SCENARIO  (EACH  (?P  :  (!  Q*V  P ) )  (PLAYERS)  (PLAY-CARD  ?P ) ) 
(TAKE-TRICK  (TRICK-WINNER)))) 

(DE  TRICK-HAS-POINTS  NIL  (HAVE-POINTS  (CAROS-Pt AYED) ) ) 

(DE  TR I CK- IN- PROGRESS  NIL  T) 

(OE  TRICK-WINNER  NIL  (PLAYER-OF  (WINNING-CARD))) 

(OE  UNCHANGEABLE  (P)  (NOT  (CAN  (CHANGE  P)))) 

(OE  UNOO  (P)  (LAMBDA  (I)  (ANO  [P  I]  [NOT  (P  (*■  I  1))]))) 

(OE  UNOOABl  F-OURING  (S  Q) 

(EXISTS  (TACT  .  (!  Q'V  ACT)) 

(ACTIONS) 

(ANO  [OURING  S  TACT]  [UNDOES  TACT  Q]))) 

[OE  UNDOES  (A  Q)  (CAUSE  A  (NOT  Q))] 

(OE  USABLE -SUCCESSORS -OF  (NOTE?) 

(SET-OF  NOTE  1  (TONES)  (USABLE -INTERVAL !  (INTERVAL  NOTE 2  NOTEl ) ) ) ) 

(Of  VOID  (P  SUIT) 

(NOT  (EXISTS  (TC  :  (I  Q'V  C) )  (CAROS -IN -HAND  P)  (1N-SU1T  ?C  SUIT)))) 
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(OE  WINNING-CARD  NIL  (HIGHEST-IN-SUIT-LED  ( CAROS - PLAYED) ) ) 
<62>r«cordf 11» 

RECORD  FILE  DSN:  (OEF319  .  QZG)  CLOSED  19-MAR-81  23 : 2S ; 51 
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Appendix  D 
Derivations 

This  appendix  describes  the  notation  used  in  the  derivations  and  presents  each  derivation  in  its 
entirety. 

D.l.  Notation  Used  in  Derivations 

The  notation  for  the  n^  step  of  DERI  Vd  is  as  follows: 

<axprassion> 

III  d : n  ---  [<rul etype>  by  RULEk]  — -> 

<expression> 

<var>  <-  <value> 

<schema>  <-  <slot>  :  <value> 

<express1on>  <-  ;  <annotat1or»> 

The  first  expression  is  a  sub-expression  of  the  current  overall  expression.  Step  n  of  derivation  d 
applies  RULEk  to  this  sub-expression,  producing  the  second  expression,  which  is  substituted  for  it. 
The  "type”  of  RULEk  is  intended  to  suggest  the  nature  of  the  transformation,  but  otherwise  has  no 
significance. 

The  three  vertical  bars  indicate  that  the  current  expression  is  part  of  a  subgoal  three  deep  on  the 
subgoal  stack.  If  this  step  were  initiating  this  subgoal,  le„  pushing  it  onto  the  stack,  it  would  be 
indicated  by 

||>  d : n  —  [<ruletypa>  by  RULEk]  — > 

Similarly,  if  it  were  satisfying  the  subgoal,  Le.,  popping  it  off  the  stack,  it  would  be  indicated  by 
||<  d:n  [<ru!etype>  by  RULEk]  ---> 

Besides  transforming  a  sub-expression  of  the  current  expression,  a  step  may  generate  some  global 
information  (§5.4),  such  as  an  assumption,  a  variable  binding,  a  slot  value  for  a  schema,  or  an 
annotation  on  an  expression.  Such  global  information  is  indicated  by  notation  following  the  new 
expression.  For  example,  the  act  of  binding  a  value  e  to  a  variable  v  is  indicated  as 


422 


§D.  Derivations 


v  <-  BINDING  :  6 

Filling  in  e  as  the  value  of  slot  p  in  schema  s  is  indicated  as 
s  <-  p  :  e 

Adding  an  annotation  to  an  expression  is  indicated  as 
e  <-  ;  <annotation> 

This  is  illustrated  at  step  2:39: 

((HAS  PI  C2)  <-  ;  (=>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME)))) 

The  act  of  assuming  that  an  expression  e  has  value  v  is  indicated  rather  clumsily  as  an  annotation: 

a  <-  ;  (->  v  if  (=  a  v)) 


D.2.  DERIV2:  Heuristic  Search  to  Avoid  Taking  Points 


RECORD  FILE  OSK:  (0V2D07  .  PZG)  OPENED  07-OEC-80  17:59:40 
NIL 

<71>p-1 Inks  nil 

(DERIV2  STARTED  "05-MAR-80  19:43:20"  --OOMAIN:  HEARTS  -PROBLEM: 
(AVOID- TAKING-POINTS  (TRICK))) 


[Initial  expression:] 

(AVOID- TAKING-POINTS  (TRICK)) 

2:1  ---  [ELABORATE  by  RULE124]  ---> 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

2:2  — -  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 

(DURING  (TRICK)  (TAKE-POINTS  ME)) 

2:3  ---  [by  RULE306]  — -> 

HSM1 

(HSM1  <-  PROBLEM  :  (DURING  (TRICK)  (TAKE-POINTS  ME))) 

(HSM1  <-  OBJECT  :  (TRICK)) 

(HSM1  <-  CHOICE- SEQ  :  (CHOICE -SEQ-OF  (TRICK))) 

>  2:4  ---  [by  RULE312]  — -> 

(CONSIDER-PROP  (CHOICE-SEQ-OF  (TRICK))) 

(TRICK) 

|  2:5  ---  [ELA80RATE  by  RULE  124]  ---> 

(SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARO  Pi)) 
(TAKE-TRICK  (TRICK-WINNER))) 

(CHOtCE-SEO-OF 

(SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER)))) 

|  2:5  ---  [DISTRIBUTE  by  RULE284]  — > 

(APPEND  (CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  Pi))) 
(CHOICE-SEQ-OF  (TAKE-TRICK  (TRICK-WINNER)))) 


♦ 


1 


(CHOICE-SEQ-OF  (TAKE-TRICK  (TRICK-WINNER))) 
—  [COMPUTE  by  RULE30B]  — > 

NIL 
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(APPEND  (CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARO  PI)))  Hit) 

|  2 : 8  ---  [SIMPLIFY  by  RULE  1 76]  — > 

(APPEND  (CHOICE-SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  Pi)))) 

|  2:9  —  [SIMPLIFY  by  RULE178]  — > 

(CHOICE -SEQ-OF  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))) 

|  2:10  ---  [DISTRIBUTE  by  RULE307 ]  — > 

(APPLY  APPEND  (EACH  PI  (PLAYERS)  (CHOICE -SEQ-OF  (PLAY-CARD  Pi)))) 

(PLAY-CARD  PI) 

|  2:11  .  — -  [ELABORATE  by  RULE124]  — -> 

(CHOOSE  (CARD-OF  PI) 

(LEGALCARDS  PI) 

(PLAY  PI  (CARD-OF  PI))) 

(CHOICE -SEQ’OF 

(CHOOSE  (CARD-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  (CARO-OF  PI)))) 

|  2:12  ---  [RECOGNIZE  by  RULE309]  ---> 

(LIST  (CHOOSE  (CARD-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  (CARD-OF  PI)))) 

(APPLY  APPEND 

(EACH  PI  (PLAYERS) 

(LIST  (CHOOSE  (CARD-OF  PI)  (LEGALCAROS  PI)  (PLAY  PI  (CARD-OF  PI)))))) 
J  2:13  — -  [SIMPLIFY  by  RULE310]  — > 

(EACH  PI  (PLAYERS) 

(CHOOSE  (CARO-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  (CARO-OF  PI)))) 


(CONSIDER-PROP 
(EACH  Pi  (PLAYERS)  ' 

(CHOOSE  (CARO-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  (CARO-OF  PI))))) 

<  2:14  ---  (by  RULE313]  ---> 

(ACHIEVE  (NOT  HSMl) ) 

(HSM1  <-  CHOICE- SEQ  . 

(EACH  PI  (PLAYERS) 

(CHOOSE  (CARO-OF  PI)  (LEGALCARDS  PI)  (PLAY  PI  ICARO-OF  Pi))))) 

HSMl 

2:16  ---  [ELABORATE  by  RULE311]  — -> 

HSMl 

(HSMl  <-  SEQUENCE  CARO-OF) 

(HSMl  <-  CHOICES  ;  (PROJECT  CARD-OF  (PLAYERS))) 

(HSMl  <-  CHOICE-SETS  .  (LAMBDA  (PI)  (LEGALCAROS  PI))) 

(HSMl  <-  INOICES  :  (PLAYERS)) 

(HSMl  <-  INOCX  :  PI) 

(HSMl  <-  VARIABLES  :  NIL) 

(HSMl  <-  BINDINGS  :  NIL) 

(HSMl  <-  INITIAL-PATH  .  NIL) 

(HSMl  <-  COMPLETION-TEST  .  (LAMBDA  (PATH)  (»  (»  PATH)  (f  (PLAYERS))))) 

>  2:16  — -  [by  RULE314]  ---> 

(CONSIOER-PROP 

(REFORMULATE  (OURING  (TRICK)  (TAKE-POINTS  ME)) 

(PROJECT  CARO-OF  (PLAYERS)))) 

(PROJECT  CARO-OF  (PLAYERS)) 

|  2:17  ---  [RECOGNIZE  by  RULE  123]  -  — > 

(CARDS-PLAYEO) 

(DURING  (TRICK)  (TAKE-POINTS  ME)) 

|  2:  IB  ---  (REDUCE  by  RULE301]  ---> 

(AND  [HAVE-POINTS  (CAROS-PLAYED) ] 

[»  (CARD-OF  ME)  (HIGHEST- IN-SUIT-LED  (CAROS-PLAYED))]) 

(REFORMULATE  (ANO  [HAVE -POINTS  (CAROS-PLAYED)] 

[*  (CARO-OF  ME)  (HIGHEST-IN-SUIT-LED  (CAROS -PLAYEO) ) ]) 
(CAROS-PLAYED)) 

J  2:19  --  [by  RULE315]  ---> 

((LAMBDA  (CAROS- PLAYEDl) 

(ANO  [HAVE-POINTS  CAROS -PLAYEDl] 

[•  (CARD-OF  ME)  (HIGHEST- IN- SUIT- LEO  CAROS-PLAYED 1 ) ] ) ) 
(CAROS-PLAYED)) 


(CONSIDER-PROP 
((LAMBOA  (CAROS- PLAYEDl) 

(ANO  (HAVE -POINTS  CARDS-PtAYEDl] 

(»  (CARO-OF  ME)  (HIGHEST- [N-SUIT-LEO  CAROS-PLAYED! ) ]) ) 
(CAROS-PLAYED))) 

<  2:20  ---  [by  RULE313]  — > 

(ACHIEVE  (NOT  HSMl)) 

(HSMl  <-  REFORMULATED -PROBLEM  : 
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t 


( ( LAMflOA  ( CAROS- PLAVEOl) 

(AMO  [HAVE -POINTS  CAROS-PLAYEDl] 

[«  (CARD-OF  ME)  (HIGHEST- IM-SUIT-LED  CAROS-PLAYEDl)])) 
(CAROS-PLAYED))) 


H$Ml 

2:21  ---  [by  RULE316]  — > 

HSMl 

(HSMl  <-  RE FORMULATED -PROBLEM  : 

((LAMBOA  (CAROS-PLAYEDl) 

(ANO  [HAVE-POINTS  CAROS-PLAYEDl] 

[»  (CARDS-PLAYEOl  ME)  (HIGHEST- IN-SUIT-LED  CAROS-PLAYEDl) ]) ) 
(CAROS-PLAYED))) 

2:22  “•  [by  RULE317]  ---> 

HSMl 

(HSM1  <-  PATH  :  CAROS- PLAYED 1) 

(HSMl  <-  STEP-OROER  :  NIL) 

(HSMl  <-  STEP-TEST  :  T) 

(HSMl  <*  PATH-ORDER  :  NIL) 

(HSMl  <-  PATH-TEST  :  T) 

(HSMl  <-  SOLUTION-TEST  : 

(LAMBOA  (CAROS-PLAYEDl) 

(ANO  [HAVE -POINTS  CAROS-PLAYEDl] 

[■  (CAROS-PLAYEDl  ME)  (HIGHEST- IN-SUIT-LED  CAROS-PLAYEDl)]))) 

>  2:23  —  [by  RULE312]  — > 

(CONSIOER- PROP  (LAMBDA  (PI)  (LEGALCAROS  PI))) 

(LEGALCAROS  PI) 

|  2:24  ---  [ELABORATE  by  RULE124]  — -> 

(SET-OF  C2  (CAROS)  (LEGAL  PI  C2)J 

(CONSIOERPROP  (LAMBOA  (PI)  (SET-OF  C2  (CARDS)  (LEGAL  PI  C2 ) ) ) ) 
<  2:25  —  [by  RULE313]  — > 

(ACHIEVE  (MOT  HSMl)) 

(HSMl  <-  CHOICE-SETS  :  (LAMBOA  (Pt)  (SET-OF  C2  (CAROS)  (LEGAL  PI  C2)))) 


HSMl 

>  2:28  ---  (by  RULE318]  — > 

(CONSIOER-PROP 

(LAMBDA  (PI)  (SET-OF  C2  (CAROS)  (POSSIBLE  (LEGAL  PI  C2 ) ) ) ) ) 

(LEGAL  PI  C2 ) 

|  2;22  ---  [ELABORATE  by  RULE124]  ---> 

(AND  (HAS  PI  C2 ] 

[->  (LEADING  PI) 

(OR  [CAN-LEAD-HEARTS  PI]  [NEQ  (SUIT-OF  C2)  H])] 

[»>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  C2  (Sl^T-LEO) ]) ]) 
(HAS  PI  C2 ) 

|>  2:28  —  [by  RULE319]  — > 

(CONSIOER- NOTE  (•>  (OUT  C7)  IF  (->  (HAS  PI  C2)  (OUT  C7)))) 

(OUT  C7) 

||  2:29  ---  [ELABORATE  by  RULE  124]  — -> 

(EXISTS  P4  (OPPONENTS  ME)  (HAS  P4  C7)) 

(«>  (HAS  Pi  C2) 

(EXISTS  P4  (OPPONENTS  ME)  (HAS  P4  C7))) 

||>  2:30  —  [by  RULE322]  --> 

(SHOW  (ANO  [IN  P4  (OPPONENTS  ME)]  [•  PI  P4]  (-  C2  C7])) 


Itl  2:31 

(P4  <-  B1NOING  :  Pi) 

III  2:3* 

( C  7  <-  6 1  NO  INC  :  C2) 


(»  PI  P4) 

—  [EVAL  by  RULE271]  — -> 
T 


(«  C2  C7> 

—  [EVAL  by  RULE271]  ---> 
T 


Ut  2:33 


(ANO  [IN  P4  (OPPONENTS  ME)]  T  T) 
---  [SIMPLIFY  by  RULE11]  ---> 
(AND  [IN  P4  (OPPONENTS  ME)]  T) 


III  2:34 


---  [SIMPLIFY  by  RULE11]  — > 
(ANO  [IN  P4  (OPPONENTS  ME)]) 


I 


< 


1 1  i  i -’H ‘i )> t - -  -- 
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III 

III 

ll< 

II  J:M 

|<  2:39 

( (HAS  PI 
(>  2:40 

II  2:41 

II  2:42 

I)  2:43 

II  2:44 

II  2  46 

II  2:46 

II  2: 47 

ll>  2:4* 


---  [SIMPLIFY  by  RULE 178]  — -> 

(IN  P4  (OPPONENTS  ME)) 

P4 

---  [EVAL  by  RULE  127]  — -> 

PI 

(SHOW  (IN  Pi  (OPPONENTS  ME))) 

—  [GIVE-UP  by  RULE  161]  — > 

( CONSIDER- NOTE  («>  (OUT  C7)  IF  (IN  Pi  (OPPONENTS  ME)))) 

C7 

---  [EVAL  by  RULE127]  — ■ -> 

C2 

(CONSIDER-MOTE  (->  (OUT  C2)  IF  (IN  Pi  (OPPONENTS  ME)))) 

— -  [by  RULE320]  — -> 

(CONSIDER-PROP 
(LAMflDA  (PI) 

(SET-OF  C2  (CAROS) 

(POSSIBLE  (AND  [HAS  PI  C2] 

[•>  (LEADING  Pi)  (OR  [CAN- LEAD -HEARTS  PI]  [NEQ  (SUIT-OF  C2)  H])] 
[«>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  C2  (SUIT-I.ED)  ])])))) ) 

C2 )  <-  ;  («>  (OUT  C2)  IF  (IN  Pi  (OPPONENTS  ME)))) 


(HAS  Pi  C2) 

[by  RULES 19]  — -> 

(CONSIDER -NOTE 

(->  (NON-VOID  P5)  IF  (O  (HAS  PI  C2)  (NON-VOID  P5)))) 

(NON-VOID  P6) 

---  [ELABORATE  by  RULE  124]  ---> 

(NOT  (VOID  P5  ( SUIT ‘LEO) ) ) 

(VOID  P5  (SUIT-LED)) 

—  -  [ELABORATE  by  RULE124]  — -> 

(NOT  (EXISTS  Cll  (CARDS- IN-HANO  P6) 

(IN-SUIT  Cll  (SUIT-LEO) ) ) ) 

(NOT  (NOT  (EXISTS  Cll  (CAROS- IN-HANO  P5) 

(IN-SUIT  Cll  (SUIT-LEO))))) 
---  [SIMPLIFY  by  RULE8B]  — > 

(EXISTS  Cll  (CARDS- IN-HANO  P6) 

(IN-SUIT  Cll  (SUIT-LEO))) 

(CAROS- IN-HAND  P6) 

---  [ELABORATE  by  RULE124]  — > 
(SET-OF  C12  (CAROS)  (HAS  P5  C12) ) 

(EXISTS  Cll  (SET-OF  C12  (CARDS) 

(HAS  P5  C12) ) 

(IN-SUIT  Cll  (SUIT-LED))) 

—  -  [by  RULE  135]  — -> 

(EXISTS  Cll  (CAROS) 

(AND  [HAS  P5  Cll] 

[IN-SUIT  Cll  (SUIT-LEO)])) 

(■>  (HAS  PI  C2) 

(EXISTS  Cll  (CAROS) 

(ANO  [HAS  PS  Cll] 

[IN-SUIT  Cll  (SUIT-LED)]))) 

— -  [by  RULE220]  — > 

(EXISTS  Cll  (CAROS) 

(■>  (HAS  PI  C2) 

(ANO  [HAS  P5  Cll] 

[IN- SUIT  Cll  (SUIT-LEO)]))) 

(•>  (HAS  PI  C2) 

(ANO  [HAS  P5  Cll] 

[IN-SUIT  Cll  (SUIT-LEO)])) 

---  [REOUCE  by  RULE321]  --*> 

(ANO  [•>  (HAS  PI  C2 )  (HAS  P6  Cll)} 
[IN-SUIT  Cll  (SUIT-LEO)]) 

(•)  (HAS  PI  C2 )  (HAS  P»  Cll)) 

--  [by  RULE91]  ---> 

(SHOW  (AND  [•  PI  P6]  [•  C2  Cll])) 


til  2: 4* 


(*  PI  PS) 

---  [EVAL  by  RULE271]  ---> 
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T 

(P6  <-  BINOING  :  Pi) 


('  C2  CU) 


III  2:»0 

---  [EVAL  by  RULE271 ]  ---> 
( 

(CU  <-  BINDING  :  C2) 

III  2:42 

(AND  T  T) 

---  [COMPUTE  by  RULE23B]  ---> 

T 

ll<  2:42 

(SHOW  T) 

---  [SUCCEED  by  RULE53]  — -> 

(CONSIDER-NOTE 
(*>  ( NON -VO 10  P5 ) 

IF  (EXISTS  CU  (CARDS)  (AND  T  [IN-SUIT  CU  (SUIT-LED)])))) 

II  2  43 

(ANO  T  [IN-SUIT  CU  (SUIT-LED)]) 

---  [SIMPLIFY  by  RULE  11]  — > 

(ANO  [IN-SUIT  CU  (SUIT-LED)]) 

II  2:44 

—  [SIMPLIFY  by  RULE17S]  ---> 
(IN-SUIT  Cll  (SUIT-LED)) 

II  2:44 

CU 

---  [EVAL  by  RULE  127 ]  ---> 
C2 

II  2:54 

(EXISTS  Cll  (CARDS)  (IN-SUIT  C2  (SUIT-LED))) 
---  [REMOVE-QUANT  by  RULE  155]  — -> 

(IN-SUIT  C2  (SUIT-LED)) 

|<  2:4? 

(CONSIDER -NOTE  (■>  (NON-VOID  P5)  IF  (IN-SUIT  C2  { SUIT-LED) ) ) ) 
---  [by  RUIE320]  ---> 

(CONSIDER-PROP 
(LAMBDA  (PI) 

(SET-Of  C2  (CARDS) 

(POSSIBLE  (ANO  (HAS  PI  CZ] 

[«>  (LEADING  Pt)  (OR  [CAN-LEAD-HEARTS  PI)  [NEQ  (SUIT-OF  C2 )  H])] 
[•>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  C2  (SUIT-LED)])]))))) 

((HAS  PI  CZ)  <-  ;  (•>  (NON -VO 10  PS)  IF  (IN-SUIT  C2  (SUIT-LED)))) 

<  2 :  58  —  [by  RULE313]  — > 

(ACHIEVE  (NOT  HSM1)) 

(HSM1  <-  CHOICE-SETS  : 

(LAMBDA  (PI) 

(SET-OF  C2  (CARDS) 

(POSSIBLE  (AND  (HAS  PI  C2] 

[»>  (LEAOING  PI)  (OR  [CAN- LEAD -HEARTS  PI]  [NEQ  (SUIT-OF  C2)  H])] 

[«>  (FOLLOWING  PI) 

(OR  (VOID  PI  (SUIT-LED)]  [IN-SUIT  C2  (SUIT-LED)])]))))) 


HSM1 

>  2:59  ---  [by  RULE323]  — > 

(CONSIDER-PROP 
(ANO  T 

(LAMBDA  (CARDS- PLAYEDl) 

(»>  (->  (.  ((PROJECT  CARO-OF  (PLAYERS))  ME) 

(HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS)))) 

(•  (CARDS* PLAYEDl  ME)  (HIGHEST- IN-SUIT-LED  CAR0S-PLAYED1 ) ) ) 

(•  (CARDS- PLAYEDl  ME)  (HI6HEST-IN-SUIT-LED  CARDS-PLAYEDt) ) ) ]) ) 

(ANO  T 

[LAMBOA  (CARDS-PLAYEDt) 

(->  (.>  (.  ((PROJECT  CARO-OF  (PLAYERS))  ME) 

(HIGHEST- IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS)))) 

(■  (CAROS-PLAYEOt  ME)  ;HIGHEST- IN-SUIT- LEO  CARDS-PLAYEDt) ) ) 
(-  (CAROS-PLAYEOt  ME)  (HIGHEST- IN-SUIT- LED  CAROS -PLAYED 1 ) ) ) ]) 

|  2 : 50  ---  [SIMPLIFY  by  RULE II]  — > 

(ANO  [LAMBOA  (CAR0$-PLAYE01 ) 

(■>  (■>  (-  ((PROJECT  CARD-OF  (PLAYERS))  ME) 

(HIGHEST- IN-SUIT-LED  (PROJECT  CARO-OF  (PLAYERS)))) 

(■  (CAROS-PLAYEOt  ME)  (HIGHEST-  rN-S(UT-l£0  CARDS -PLAYEDl) )  ) 
<-  (CARDS-PLAYED1  ME)  (HIGHEST- IN-SUIT-LEO  CARDS -PLAYEDl ) ) ) ]) 

I  2: §1  —  [SIMPLIFY  by  RULE178]  — > 

(LAMBOA  (CAROS-PLAYEOl) 

C>  (•>  ("  ((PROJECT  CARO-OF  (PUYERS))  ME) 

(HIGHEST- IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS)))) 
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(*  (CAROS-PLAYEDl  ME)  (HIGHEST-IN-SUIT-LED  CAROS-PLAYEDl ) ) ) 

(»  (CAAOS-PLAYEDl  ME)  (HIGHEST- IN- SUIT-LED  CAROS - PLAYED1) )) ) 

(»>  (•  ((PROJECT  CARO-Of  (PLAYERS))  ME) 

(HIGHEST- IN-SUIT-LEO  (PROJECT  CARD-OF  (PLAYERS)))) 

(*  { CARDS- PLAYED1  ME)  ( H IGHEST- IN- SUIT-LED  CAROS-PLAYED1) ) ) 
l>  2:62  ---  [by  RULE91]  — > 

(SHOW  (AMO  [*  ((PROJECT  CARO-OF  (PLAYERS))  ME)  (CAROS-PLAYED1  ME)] 

[-  (HIGHEST- IN- SUIT-LED  (PROJECT  CARO-OF  (PLAYERS))) 
(HIGHEST- IN- SUIT- LEO  CAROS-PLAY EDI ) ] ) ) 


||>  2:63 


||<  2:64 


II  2:66 


||>  2:66 


(«  (HIGHEST- IM-SUIT-LED  (PROJECT  CARO-OF  (PLAYERS))) 
(HIGHEST- IN-SUIT-LED  CAROS-PLAYED1 ) ) 

---  [by  RULE324]  ---> 

(SHOW  (SU8SET  CAROS-PLAYEDl  (PROJECT  CARO-OF  (PLAYERS)))) 

---  [ASSUME  by  RULE32]  ---> 

(SHOW  (AND  [»  ((PROJECT  CARD-OF  (PLAYERS))  ME)  ( CARDS- PLAYED1  ME)] 
[IN  (HIGHEST- IN- SUIT-LED  (PROJECT  CARD-OF  (PLAYERS))) 
CAROS-PLAYEDl]) ) 

(HIGHEST-IN-SUIT-LED  (PROJECT  CARD-OF  (PLAYERS))) 
---  [REDUCE  by  RULE301]  ---> 

((PROJECT  CARD-OF  (PLAYERS))  ME) 

(*  ((PROJECT  CARD-OF  (PLAYERS))  ME)  (CAROS-PLAYEDl  ME)) 
—  -  [by  RULE325]  — > 

(SHOW  (SUBSET  CAROS-PLAYEDl  (PROJECT  CARD-OF  (PLAYERS)))) 


ll<  2:67 


||  2  66 


II  2:69 


II  2  20 


---  [ASSUME  by  RULE32]  ---> 

(SHOW  (AND  [IN  ME  (INDICES-OF  CAROS-PLAYEDl) ] 

[IN  ((PROJECT  CARO-OF  (PLAYERS))  ME)  CARDS- PLAYED1 ] ) ) 

((PROJECT  CARO-OF  (PLAYERS))  ME) 

---  [REDUCE  by.  RULE301]  ---> 

(CAROS-PLAYEDl  ME) 


(IN  (CAROS-PLAYEDl  ME)  CAROS-PLAYEDl) 
---  [REDUCE  by  RULE326]  ---> 

(IN  ME  (INOICES-QF  CAROS-PLAYEDl)) 


(AND  [IN  ME  (INDICES-OF  CAROS-PLAYEDl)] 
[IN  ME  (INDICES-OF  CARDS-PLAYED1) ]) 
[SIMPLIFY  by  RULE  188]  ---> 

(AND  [IN  ME  (INDICES-OF  CAROS-PLAYEDl)]) 


|)  2: 71  ---  [SIMPLIFY  by  RULE  178]  ---> 

(IN  ME  (INDICES-OF  CAROS-PLAYEDl) ) 


(SHOW  (IN  ME  (INDICES-OF  CARDS-PLAYED1) ) ) 

|<  2:72  ---  [GIVE-UP  by  RULE  161 ]  — -> 

(COMSIOER-PROP 
(LAMBDA  ( CARDS -PLAYED1) 

(»>  (IN  ME  (INDICES-OF  CAROS-PLAYEDl)) 

(>  (CAROS-PLAYEDl  ME)  (HIGHEST- I N- SUIT- LEO  CARDS - PLAYEOl ) ) ) ) ) 


<  2:73  ---  [by  RULE313]  ---> 

(ACHIEVE  (NOT  HSM1)) 

(HSM1  <-  PATH- TEST  : 

(LAMBDA  (CAROS-PLAYEDl) 

(•>  (IN  ME  (INOICES-OF  CAROS-PLAYEDl)) 

(*  (CAROS-PLAYEDl  ME)  (HIGHEST-IN-SUIT-LED  CAROS-PLAYEDl) ) ) ) ) 


HSM1 

>  2:74  ---  [by  RULE327]  — -> 

(SHOW  (»  («>  ( IN  ME  (INDICES-OF  CAROS-PLAYEDl) ) 

(«  (CAROS-PLAYEDl  ME)  (H IGHEST- IN-SUIT-LED  CAROS-PLAYEDl) ) ) 
(FORALL  PI  (INOICES-OF  CAROS-PLAYEDl )  Ql))) 


|  2:78 
|  2:76 


(HIGHEST- IN-SUIT- LED  CAROS-PLAYEDl) 

-  [ELABORATE  by  RULE124]  — -> 

(HIGHEST  (CARDS- IN-SUIT-LED  CAROS-PLAYEDl)) 

---  [ELABORATE  by  RULE124]  ---> 

(THE  CIS  (CAROS- IN-SUIT-LEO  CAROS-PLAYEDl) 

(FORALL  XI  (CAROS- IN-SUIT- LEO  CAROS-PLAYEDl) 
(NOT  (HIGHER  XI  CIS)))) 

(»  (CARDS-PLAYEOl  ME) 

(THE  CIS  (CARDS- IN-SUIT-LED  CAROS-PLAYEDl) 

(FORALL  XI  (CARDS- IN- SUIT -LED  CARDS-PLAYEOl) 
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|  2:77 

}  2:78 

{  2.79 

|  2:80 

|  2  81 

|  2:82 


|  2:83 

|  2:84 
(01  <* 

<  2:85 

2:86 

2:87 

2:86 


(MOT  (HIGHER  II  CIS))))) 

---  [UHB RACKET  by  RULE64]  ---> 

(AND  [IN  (CARDS-PLAYEOl  ME)  (CAROS* IN 'SUIT -LED  CARDS-PLAYEDI)] 

[FORALL  XI  (CARDS-IN  SUIT-LED  CARDS- PLAYEDl) 

(NOT  (HIGHER  II  (CAROS-PIAVEDI  ME))))) 

(CAROS- IN- SUIT- LED  CAROS -PLAYEDl) 

---  [ELABORATE  by  RULE  124]  ---> 

(SET-OF  C19  CAROS-PLA YEOl  (*  (SUIT-Of  C19)  (SUIT-LED))) 

(FORALL  XI  (SET-OF  Cl9  CARDS-PLAYEDI  (*  (SUIT-OF  C19)  (SUIT-LED))) 
(NOT  (HIGHER  XI  (CARDS - PLAYEDl  HE)))) 

—  [by  RULE 2 19]  — > 

(FORALL  XI  CAROS-PLAYEDi 

C>  (*  (surr-oF  xij  ( suit-led )) 

(NOT  (HIGHER  XI  (CAROS-PLAYEDI  ME))))) 

---  (by  RULE328]  — > 

(FORALL  PI  (INOICES-OF  CAROS-PLAYEOl) 

(*>  (»  (SUIT-OF  (CARDS- PLAYEDl  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEOl  PJ )  (CAROS -PLAYEDl  ME))))) 

(»>  (IN  ME  ( INO ICES-OF  CAROS-PLAYEOl J ) 

(ANO  [IN  (CARDS- PLAYEDl  ME)  (CARDS* IN- SUIT-LED  CARDS-PLAYEDI) ] 

[FORALL  PI  (INOICES-Of  CAROS-PLAYEOl ) 

(•>  (*  (SUIT-OF  (CAROS-PLAYEOl  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEOl  PI)  (CARDSPLAYEDl  ME))))])) 

---  [by  RULE329]  — -> 

(FORALL  PI  (INOICES-OF  CAROS-PLAYEOl ) 

(»>  (IN  ME  ( IND ICES-OF  CARDS-PLAYED1 ) ) 

(AND  [IN  (CAROS-PLAYEOl  ME)  (CAROS- IN- SUIT-LED  CAROS-PLAYEDI) ] 

[*>  (*  (SUIT-OF  (CAROS-PLAYEDI  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLA YEOl  PI)  (CAROS-PLAYEDI  ME)))]))) 

---  [by  RULE330]  — -> 

(FORALL  PI  (INDICES-Of  CAROS-PLAYEDI) 

(»>  (NOT  (AFTER  ME  PI)) 

(AND  [IN  (CAROS-PLAYEDI  ME)  (CARDS- IN-SUIT-LED  CAROS-PLAYEDI)] 

[*>  (»  (SUIT-OF  (CAROS-PLAYEDI  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEDI  PI)  ( CARDS- PLAYEDl  ME)))]))) 

(»  (FORALL  PI  (INOICES-OF  CAROS-PLAYEDi) 

(■>  (NOT  (AFTER  ME  PI)) 

(AND  [IN  (CARDS-PLAYEDI  ME)  (CARDS- IN-SUIT -LED  CAROS-PLAYEDI) ] 

[•>  (*  (SUIT-OF  (CAROS-PLAYEOl  P1)J  (SUIT-LED)) 

(NOT  (HIGHER  (CARDS-PLAYEDI  PI)  (CAROS-PLAYEDI  ME)))]))) 
(FORALL  PI  (INOICES-OF  CAROS-PLAYEOl)  Ql ) } 

—  [REDUCE  by  RULE192]  — > 

(*  (->  (NOT  (AFTER  ME  Pt)) 

(AND  [IN  (CAROS-PLAYEOl  ME)  (CAROS-IN-SUIT-LED  CARDS-PLAYEOl ) ] 

{*>  (*  (SUIT-OF  (CAROS-PLAYEDI  PI))  (SUrT-LEO)) 

(NOT  (HIGHER  (CAROS-PLAYEDI  PI)  (CARDS-PLAYEOl  ME)))])) 

01) 


—  [EVAL  by  RULE271]  — -> 

T 

8INOING  : 

‘  (NOT  (AFTER  ME  Pi)) 

(AND  [IN  (CARDS-PLAYEOl  ME)  (CARDS- IN - SUIT-LEO  CARDS-PLAYEDt) ] 

[*>  (*  (SUIT-OF  (CAROS-PLAYEDI  Pi))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEDI  PI)  (CAROS-PLAYEDi  ME)))]))) 


(SHOW  T) 

---  [SUCCEED  by  RULE34]  ---> 

(ACHIEVE  (NOT  (THEN  SCONSIOER-PROP  HSM1  STEP-TEST 

(ANO  T  [LAMBOA  (PI  C21)  (THEN  SSUBST  C21  (CARDS-PLAYEDI  Pi)  01)])))) 

(AND  T  [LAMBOA  (PI  C21)  (THEN  tSUBST  C21  (CARDS-PLAYEDI  Pi)  Ql)]) 

---  [SIMPLIFY  by  RUlEU]  -*-> 

(ANO  [LAMBOA  (PI  C21)  (THEN  SSU8ST  C21  (CARDS-PLAYEDI  PI)  Ql)]) 

---  [SIMPLIFY  by  RULE178]  — > 

(LAMBOA  (PI  C21)  (THEN  JSUBST  C21  (CAROS-PLAYEDt  PI)  Ql)) 

01 

---  [EVAL  by  RULE127]  ---> 

(*>  (NOT  (AFTER  ME  PI)) 

(ANO  [IN  (CAROS-PLAYEOl  ME)  (CAROS- IN-SUIT -LEO  CAROS-PLAYEDi)] 
[«>  (-  (SUIT-OF  (CAROS-PLAYEDI  Pt))  (SUIT-LED)) 

(NOT  (HIGHER  (CARDS-PLAYEDI  Pi)  (CARDS-PLAYEOl  Ml)))])) 
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(THEM  SSUBST  C21  ( CAROS-PLAYEDl  PI) 

(*>  (NOT  (AFTER  ME  Pi)) 

(ANO  [IN  (CAROS-Pl  AYEOl  ME)  (CAROS-  IN- SUIT-LEO  CARDS-PLAYEOl)] 

[*>  («  (SUIT-Of  (CAROS-PLAYEDl  PI))  (SUIT-LED)) 

(NOT  (HIGHER  (CAROS-PLAYEDl  PI)  (CARDS-PLAYEOl  ME)))]))) 
2.89  ---  [SIMPLIFY  by  RVJLE331)  ---> 

(O  (NOT  (AFTER  ME  PI)) 

(ANO  [IN  ( CAROS-PLAYEDl  ME)  ( CAROS- IN- SUIT- LED  CAROS-PLAYEDl)] 

[«>  l-  (SUIT-OF  C2l)  (SUIT-LED)) 

(NOT  (HIGHER  C21  (CARDS-PLAYEOl  ME)))])) 

(CARDS- IN-SUIT-LED  CAROS-PLAYEOl) 

2:90  ---  (ELABORATE  by  RULE  124]  — -> 

(SET-OF  C22  CAROS-PLAYEDl  (»  (SUIT-OF  C22)  (SUIT-LED))) 

(IN  (CAROS-PLAYEOl  ME) 

(SET-OF  C22  CAROS-PLAYEOl  (•  (SUIT-OF  C22)  (SUIT-LED)))) 

2:91  ---  [REMOVE-QUANT  t>y  RULE10]  -«-> 

(ANO  [IN  (CAROS-PLAYEDl  ME)  CAROS-PLAYEDl] 

[*  ( SUIT -Of  (CAROS-PLAYEOl  ME))  (SUIT-LED)]) 

2:92  ---  (REDUCE  by  RULE301]  — > 

(•  (SUIT-Of  (CARDSPLAYEDl  ME))  (SUIT-LED)) 

(THEN  SCONSIDER-PROP  HSM1  STEP-TEST 
(LAMBDA  (PI  C21) 

(*>  (NOT  (AFTER  ME  PI)) 

(AND  [■  (SUIT-OF  (CAROS-PLAYEDl  ME))  (SUIT-LED)] 

(*>  (  =  (SUIT-OF  C21)  (SUIT-LED)) 

(NOT  (HIGHER  C21  (CARDS-PLAYEOl  ME)))])))) 

293  ---  [by  RULE332]  ---> 

(THEN  SCONSIDER-PROP  HSM1  STEP-TEST 
(LAMBDA  (PI  C21) 

(»>  (NOT  (AFTER  ME  PI)) 

(ANO  [•  (SUIT-OF  MY-CARD4)  (SUIT-LEO)] 

[->  (•  (SUIT-OF  C21)  (SUIT-LEO) )  (NOT  (HIGHER  C21  MY-CARD4) )])))) 

(HSM1  <-  VARIABLES  :  (MY-CAR04) ) 

(HSM1  <-  BINDINGS  :  ((CARD-OF  ME))) 

(HSM1  <-  INITIAL-PATH  (PROJECT  CARD-OF  (PREFIX  (PLAYERS)  ME))) 

2:94  ---  [by  RULE 333]  ---> 

(THEN  SCONSIDER-PROP  H$M1  STEP-TEST 
(LAMBDA  (PI  C21) 

(«>  (NOT  (AFTER  ME  PI)) 

(AND  [«  (SUIT-OF  MY-CAR04)  SUIT-LE02] 

[«>  (-  (SUIT-Of  C21)  SUIT  - LED2 )  (NOT  (HIGHER  C21  MV-CARD4) )])))) 

(MSM1  <-  BINDINGS  :  ((SUIT-LED)  (CARD-OF  ME))) 

(HSM1  <-  VARIABLES  :  (SUIT-LED2  MY-CAR04) ) 

2:95  — -  [SIMPLIFY  by  RULE334]  ---> 

HSM1 

(HSM1  <-  STEP-TEST  : 

(LAM80A  (PI  C21) 

(->  (NOT  (AFTER  ME  PI)) 

(AMD  [*  (SUIT-OF  MY-CARD4)  SUIT-LE02] 

[*>  («  (SUIT-OF  C21)  SUIT-LED2 )  (NOT  (HIGHER  C2l  MY-CAR04) )])))) 

>  2:95  ---  [by  RULE335]  ---> 

(SHOW  (*>  (HAVE-POINTS  (PREFIX  CAROS-PLAYEOl  ANY)) 

(HAVE -POINTS  CAROS-PLAYEDl))) 

(«>  (HAVE-POINTS  (PREFIX  CAROS-PLAYEDl  ANY)) 

(HAVE -POINTS  CAROS-PLAYEDl)) 

|>  2:97  ---  [REDUCE  by  RULE336]  ---> 

(SHOW  (SU8SET  (PREFIX  CAROS-PLAYEDl  ANY)  CAROS-PLAYEDl)) 

(SUBSET  (PREFIX  CARDS-PLAYEOl  ANY)  CAROS-PLAYEOl) 

||  2:98  ---  [EVAL  by  RULE337]  --> 


(SHOW  T) 

|<  2:99  ---  [SUCCEED  by  RULE63]  — > 

(SHOW  T) 

<  2:100  — -  [SUCCEEO  by  RULE34]  — -> 

(ACHIEVE  (NOT  HSM1)) 

Hsm 

>  2:101  ---  [by  RUIE338]  ---> 

(CONSIDIR-PROP 

(LAMBDA  (PI  C21 )  (HAVE-POINTS  (APPEND  CAROS-PLAYEDl  (LIST  C21))))) 
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(HAVE 'POlMTS  (APPEND  CAROS-PLAYEOl  (LIST  C21))) 

|  2:102  [DISTRIBUTE  by  RULE284]  ---> 

(OR  [HAVE-POINTS  CAROS-PLAYEDl]  [HAVt-POINTS  (LIST  CZ1)]J 

(HAVE-POINTS  (LIST  C21)) 

|  2:103  [ELABORATE  by  RULE124)  — -> 

(EXISTS  C23  (LIST  C21)  (MAS-POINTS  C23) ) 

|  2:104  ---  [SIMPLIFY  by  RULE266]  — > 

(HAS-POINTS  C21) 

(CONSIDER- PROP 

( LAMBDA  (PI  C21)  (OR  [HAVE-POINTS  CAROS-PUYED1 )  [HAS-POINTS  C21J))) 

<  2  IBS  ---  (by  RULE313]  — > 

(ACHIEVE  (NOT  HSM1 ) ) 

(HSM1  <-  STEP-ORDER  : 

(LAMBDA  (PI  C21)  (OR  [HAVE-POINTS  CAROS -PLAY EDI]  [NAS'POINTS  C21]))) 

(F^nAl  expression:  ] 

(ACHIEVE  (NOT  HSMt)) 

NIL 

<?2>p  hs»l 


(HSM1  WITH  (PROBLEM  :  (OljRtMG  (TRICK)  (TAKi'POlMTS  ME))) 
(OBJECT  :  (TRICK) ) 

(CHOICE -SEQ  . 

(EACH  PI  (PLAYERS) 

(CHOOSE  (CARO-OF  PI) 

(LEGALCARDS  PI) 

(PLAY  PI  (CARD-OF  PI))))) 

(SEQUENCE  CARO-OF) 

(CHOICES  (PROJECT  CARO-OF  (PLAYERS))) 

(CHOICE-SETS  : 

(LAMBDA  (PI) 

(SET-OF  C2  (CAROS) 

(POSSIBLE  (AMO  [HAS  Pi  C2] 

(*>  (LEADING  PI) 


(OB  [CAN -LEAD -HEARTS  PI] 

[NEQ  (SUIT-OF  C2)  H])] 

[»>  (FOLLOWING  Pi) 

(OR  [VOID  PI  (SUIT-LED)] 

[IN-SUIT  C2  ( SUIT-LED)]))) ) 


m 

(INDICES  :  (PLAYERS)) 

(INOEX  :  PI) 

(COMPLETION-TEST  :  (LAHBOA  (PATH)  (*  (#  PATH)  (M  (PLAYERS))))) 
(REfQRMULATED-PROBLEM  : 

((LAMBDA  (CAROS- PLAYEDt) 

l AND  [HAVE  POINTS  CAROS-PLAYEOl] 

[>  (CAROS-PLAYEOl  ME)  (HIGHEST- JN-SUJT-LfD  CARDS-PLAYEDl)})) 
(CARDS'PLAYED) ) ) 

(PATH  :  CAROS-PLAYEOl) 

(STEP-OROER  : 

(LAMBDA  (PI  C21) 

(OR  [HAVE-POINTS  CAROS-PLAYEOl]  [HAS-POINTS  C21]))) 

(STEP-TEST  . 

(LAMBDA  (PI  C21) 

(*>  (NOT  (AFTER  ME  Pi)) 

(AND  [•  (SUIT-OF  MY-CARD4)  SUIT-LED2] 

[»>  («  (SUIT-OF  C21)  SUIT -LED2) 

(NOT  (HIGHER  C21  MY-CAR04) )])))) 

(PATH-ORDER  :  (LAMflOA  (CAROS-PLAYEOl)  (HAVE-POINTS  CAROS-PLAYEOl))) 
(PATH-TEST  : 

(LAMBDA  (CAROS-PLAYEOl) 

(•>  (IN  ME  (INOtCES-OF  CAROS-PLAYEOl)) 

(«  (CAROS-PLAYEOl  ME) 

(HIGHEST -IN- SUIT -LEO  CAROS-PLAYEOl) ) ) ) ) 

(SOLUTION- TEST  : 

(LAHBOA  (CAROS-PLAYEOl) 

(ANO  [HAVE-POINTS  CAROSPtAYEDl] 

[»  (CAROS-PLAYEOl  ME)  (HIGHEST- I N- SUIT -LEO  CAROS-PLAYEOl)]))) 
(VARIABLES  .  ( SUIT -LED?  MY-CAR04) ) 

(BINDINGS  ( ( SUIT-LEO)  (CARO-OF  ME))) 

(INITIAL-PATH  .  (PROJECT  CARO-OF  (PREFIX  (PLAYERS)  Mi)))) 

H$m 

<73>p  no** 184 


(N00E184  (HAS  PI  C2) 

;  (*>  (NON-VOID  P5)  IF  (IN-SUIT  C2  (SUIT-LED))) 
(•>  (OUT  C2)  IF  (IN  PI  (OPPONENTS  ME)))) 


* 
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NOOE184 

<74>r#cordf 11# 

RECORD  FILE  OSK:  (0V2007  PZG)  CLOSED  07-DEC-80  18:11:01 


D.3.  DERIV3:  Flush  the  Queen 


RECORD  FILE  OSK;  (OV3O07  .  PZG)  OPENED  20-MAR-81  21:51:19 
NIL 

<50>p-1 Inks  nil 

(OERIV3  STARTED  "Q7-APR-80  22:32:38"  --DOMAIN:  HEARTS  —  PR08LEM: 
(ACHIEVE  (FLUSH  QS ) ) ) 


(Initial  expression:] 
(ACHIEVE  (FLUSH  QS)) 


3.1 

(FLUSH  QS) 

---  [ELABORATE  by  RULE124]  ---> 

(MUST  (OWNER-OF  QS)  (PLAY  (OWNER-OF  QS)  QS)) 

3:2 

(OWNER-OF  QS) 

[RECOGNIZE  by  RULE123]  — -> 

(QSO) 

3:3 

(OWNER-OF  QS) 

---  [RECOGNIZE  by  RULE  123]  — > 

(QSO) 

3:4 

(MUST  (QSO)  (PLAY  (QSO)  QS)) 

-  [ELABORATE  by  RULE  124]  ---> 

<-  (ACTIONS-OF  (QSO))  (PLAY  (QSO)  QS)) 

3:5 

(ACTIONS-OF  (QSO)) 

---  (REDUCE  by  RULE61]  ---> 

(PLAY-CARO  (QSO)) 

3:8 

---  [ELABORATE  by  RULE124]  — > 

(CHOOSE  (CARD -OF  (QSO)) 

(LEGALCARDS  (QSO)) 

(PLAY  (QSO)  (CARD-OF  (QSO)))) 

3:  7 

(•  (CHOOSE  (CARO-OF  (QSO)) 

(LEGALCAROS  (QSO)) 

(PLAY  (QSO)  (CARO-OF  (QSO)))) 

(PLAY  (QSO)  QS)) 

---  [REDUCE  by  RUU339]  ---> 

(*  (LEGALCARDS  (QSO))  (SET  QS)) 

3:  12 

-  [ELABORATE  by  RULE340]  ---> 

(ANO  [SUBSET  (LEGALCAROS  (QSO))  (SET  QS)] 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))]) 

>  3:13 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))) 

—  [by  RULE268]  — > 

(CONSIDER  (SUBSET  (SET  QS)  (LEGALCARDS  (QSO)))) 

)  3:14 

(SUBSET  (SET  QS)  (LEGALCARDS  (QSO))) 

—  -  [DISTRIBUTE  by  RULE17]  -  — > 

(AND  [IN  Q$  (LEGALCARDS  (QSO))]) 

|  3:  16 

—  -  [SIMPLIFY  by  RULE  178]  — > 

(IN  QS  (LEGALCAROS  (QSO))) 

1  3:16 

(LEGALCARDS  (QSO)) 

---  [ELABORATE  by  RULE124]  ---> 

(SET-OF  Cl  (CAROS)  (LEGAL  (QSO)  Cl)) 

|  3: 17 

(IN  QS  (SET-OF  Cl  (CARDS)  (LEGAL  (QSO)  Cl))) 
---  [REMOVE-QUANT  by  RULE10]  —  > 

(AND  [IN  QS  (CAROS)]  [LEGAL  (QSO)  QS]) 


(IN  QS  (CARDS)) 
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|  3:18 

|  3:19 

|  3:20 

|  3:21 

1  3:22 

|  3:23 

|  3:24 

I  3:25 

(  3:28 
((SUIT 

(  3:27 

|  3:28 

|  3:29 

I  3:30 

|  3:31 

|  3:32 

|  3:33 


—  [EVAL  by  RULE62]  ---> 

T 

(AMO  T  (LEGAL  (QSO)  QS]) 

—  [SIMPLIFY  by  RULE341]  ---> 

(LEGAL  (QSO)  OS) 

---  (ELABORATE  by  RUIE124]  — > 

(AMD  [HAS  (QSO)  QS] 

[•>  (LEADING  (QSO)) 

(OR  [CAM- LEAD-HEARTS  (QSO)]  [NEQ  (SUIT-OF  QS)  H])] 

[*>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IM-SUIT  QS  (SUIT-LED)])]) 
(QSO) 

—  [ELABORATE  by  RULE124]  ---> 

(OWMER'OF  QS) 

(HAS  (OWMER-OF  QS)  QS) 

---  [EVAL  by  RULE  1 ]  ---> 

T 

(AMO  T 

(*>  (LEADING  (QSO)) 

(OR  [CAM- LEAO-HEARTS  (QSO)]  [NEQ  (SUIT-OF  QS)  H])] 

(«>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IM-SUIT  QS  (SUIT-LED)])]) 
---  (SIMPLIFY  by  RULE  11]  ---> 

(AMO  (»>  (LEADING  (QSO)) 

(OR  [CAM -LEAD- HEARTS  (QSO)]  [NEQ  (SUIT-OF  QS)  H])] 

[•>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IN-SUIT  QS  (SUIT-LED)])]) 

(IN-SUIT  QS  (SUIT-LED)) 

---  (ELABORATE  by  RULE  124]  ---> 

(-  (SUIT-OF  QS)  (SUIT-LED)) 

(SUIT-OF  QS) 

---  [EVAL  by  RULE2]  --> 

S 

(»  S  (SUIT-LED)) 

---  (by  RULE 342]  — -> 

T 

LED)  <-  ;  (->  S  IF  (-  (SUIT-LED)  S))) 

(OR  [VOID  (QSO)  (SUIT-LED)]  T) 

---  [EVAL  by  RULE  184]  ---> 

T 

(«>  (FOLLOWING  (QSO))  T) 

---  [EVAL  by  RULE47]  — -> 

T 

(AND  [»>  (LEADING  (QSO)) 

(OR  (CAN-LEAD  HEARTS  (QSO)]  (NEQ  (SUIT-OF  QS)  H])] 

T) 

---  [SIMPLIFY  by  RULE  11]  ---> 

(AND  [■>  (LEADING  (QSO)) 

(OP  [CAN- LEAO-HEARTS  (QSO)]  [NEQ  (SUIT-Of  QS)  H])]) 
(SUIT-OF  QS) 

—  [EVAL  by  RULE 2]  — -> 

S 

(NEQ  S  H) 

— -  [COMPUTE  by  RULE 238]  — > 

T 

(OR  [CAN- LEAO-HEARTS  (QSO)]  T) 

---  [EVAL  by  RULE  134]  ---> 

T 

(■>  ( LEAOING  (QSO))  T) 

---  [EVAL  by  RULE47]  ---> 

T 


|  3:34 


(AND  T) 

—  [COMPUTE  by  RULE236]  — -> 
T 
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<  3:36 

3:36 

3:37 

3  36 

3:36 

3:44 

3:41 

3:42 

3:43 

3:44 

3:46 

>  3:46 

|  3:47 
I  3:46 

|  3:46 


(CONSIDER  7) 

---  (by  RULE269]  — > 

(ACHIEVE  (ANO  [SUNSET  (LEGALCAROS  (QSO) )  (SET  QS)]  I)) 

(AND  [SUNSET  (LEGALCAROS  (QSO))  (SET  QS)}  T) 

•—  (SIMPLIFY  ly  RULE343]  — > 

(SUNSET  (LEGALCARDS  (QSO))  (SET  QS)) 

—  [TRV-THIS  6y  RULE4] - > 

(EMPTY  (DIFF  l  LEGALCARDS  (QSO))  (SET  QS))) 

(ACHIEVE  (EMPTY  (D IFF  (LEGALCAROS  (QSO))  (SET  QS)))) 

—  -  [REDUCE  By  RULES]  — > 

(UNTIL  (PLAYED I  QS) 

(ACHIEVE  ( REMOVE- l-FROM  (DIFF  (LEGALCAROS  (QSO))  (SET  QS))))) 

(LEGALCAROS  (QSO)) 

—  [ELANORATE  By  RULE124]  - > 

(SET -OF  C3  (CAROS)  (LEGAL  (QSO)  C3 ) ) 

(01 FF  ( SET -OF  C3  (CAROS)  (LEGAL  (QSO)  C3))  (SET  QS)) 
—  [COLLECT  By  RULES]  — > 

(SET-OF  CO  (OIFF  (CARDS)  (SET  QS))  (LEGAL  (QSO)  C3)) 


(REMOVE- l-FROM 

(SET-OF  C3  (OIFF  (CAROS)  (SET  QS))  (LEGAL  (QSO)  CO))) 

—  [REOUCE  By  RULE7]  — > 

(UNDO  (ANO  [IN  CO  (OIFF  (CAROS)  (SET  QS))]  [LEGAL  (QSO)  CO])) 


---  [REDUCE  by  RULE 36]  - > 

(ANO  [UNDO  (LEGAL  (QSO)  CO)}  [IN  CO  (DIFF  (CARDS)  (SET  QS))]) 

(LEGAL  (QSO)  C3) 

---  (ELA80RATE  By  RULE124]  •— > 

(ANO  [HAS  (QSO)  C3] 

[■>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)]  [NEQ  (SUIT-OF  CO)  H])] 

[•>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IN-SUIT  CO  (SUIT-LED)])]) 

(UNOO  (ANO  [HAS  (QSO)  CO] 

[•>  (LEADING  (QSO)) 

(OR  (CAN-LEAO-HEARTS  (QSO)]  [NEQ  (SUIT-OF  CO)  H])] 

[•>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IN-SUIT  CO  (SUIT-LED)])])) 
---  [REDUCE  by  RULE36]  — > 

(ANO  [UNOO  (HAS  (QSO)  CO)] 

(•>  (LEAOING  (QSO)) 

(OR  [CAN-LEAO-HEARTS  (OSO)]  [NEQ  (SUIT-OF  CO)  H])] 

[•>  (FOLLOWING  (QSO)) 

(OR  [VOIO  (QSO)  (SUIT-LED)]  [IN-SUIT  CO  (SUIT-LED)])]) 

(ANO  [ANO  [UNDO  (HAS  (QSO)  CO)] 

[•>  (LEAOING  (QSO)) 

(OR  [CAN-LEAO-HEARTS  (QSO)]  [NEQ  (SUIT-OF  CO)  H])] 

[->  (FOLLOWING  (QSO)) 

(OR  [VOIO  (QSO)  (SUIT-LED)]  [IN-SUIT  CO  (SUIT-LED)])]] 

[IN  CO  (OIFF  (CARDS)  (SET  QS))]) 

—  [SIMPLIFY  By  RULE177]  -— > 

(AND  [UNOO  (HAS  (QSO)  CO)] 

[«>  (LEAOING  (QSO)) 

(OR  [CAN-LEAO-HEARTS  (OSO)]  [NEQ  (SUIT-OF  CO)  H])J 
[■>  (FOLLOWING  (QSO)) 

(OR  [VOIO  (QSO)  (SUIT-LED)]  [IN-SUIT  C3  (SUIT-LED)])] 

[IN  CO  (OIFF  (CARDS)  (SET  QS))]) 

(UNOO  (HAS  (QSO)  CO)) 

—  [by  RUIE2S4]  ---> 

(SHOW  (•>  (PLAY  PI  C4)  (UNDO  (HAS  (QSO)  CO)))) 

(HAS  (QSO)  CO) 

—  [ELANORATE  by  RULE  124]  — > 

(AT  CO  (HARO  (QSO))) 

—  [ELANORATE  by  RULES24]  — > 

(•  (LOC  CO)  (HANO  (QSO))) 

(UNOO  (•  (LOC  CO)  (HANO  (QSO)))) 

—  [by  RULE344]  ---> 

(ANO  [•  (LOC  CO)  (NANO  (QSO))]  [SECOME  (LOC  CO)  LOCO]) 


434 


§D.  Derivations 


|  3 :  SO 

|  3:51 

|  3:52 

|  3:53 
(C4  <- 

|  3:54 
( LOC3  < 

|  3:56 

|  3:56 

(PI  <- 

|  3:57 

I  3 59 

<3:59 

3:60 

3:51 

3:62 

3:6) 

>  3:84 

|  3  65 

|  3:66 

|  3:67 


BINDING  :  C3) 


-  BINDING  :  POT) 


BINOING  :  (QSO) ) 


—  [RECOGNIZE  by  RULE123]  — *> 

(MOVE  C3  (HAND  (QSO))  LOC3) 

(PLAY  PI  C4 ) 

---  [ELABORATE  by  RULE124]  — -> 

(WVE  C4  (HAND  PI)  POT) 

(»>  (MOVE  C4  (HANO  PI)  POT)  (MOVE  C3  (HAND  (QSO))  L0C3)) 
---  [DISTRIBUTE  by  RULE43]  — > 

(ANO  [*  C4  C3 ]  [»  (HANO  PI)  (HANO  (QSO))]  [»  POT  LOC3]) 
(•  C4  C3) 

—  [REDUCE  by  RULE  194]  — -> 

T 


(•  POT  LOC3) 

—  [EVAL  by  RULE271]  - > 

T 


(*  (HANO  PI)  (HAND  (QSO))) 

—  (DISTRIBUTE  by  RULE43]  ---> 
(AND  [•  PI  (QSO)]) 

(»  PI  (QSO)) 

---  [REDUCE  by  RULE  194]  ---> 
T 


(AND  T) 

---  (COMPUTE  by  RULE236]  — -> 
T 


(ANO  T  T  T) 

---  [COMPUTE  by  RULE238J  — > 


(SHOW  T) 

---  (SUCCEED  by  RULE34]  ---> 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE  (AND  [PLAY  PI  C4] 

[*>  (LEADING  (QSO)) 

(OR  [CAN-LEAO-HEARTS  (QSO)]  [WCQ  {SUtT-OF  C3 }  «])] 

(•>  (FOLLOWING  (QSO)) 

(OR  [VOID  (QSO)  (SUIT-LED)]  [IN-SUIT  C3  (SUIT-LED)])] 
[IN  C3  (DIFF  (CAROS)  (SET  QS))]))) 

PI 

—  [EVAL  by  RULE127]  — > 

(QSO) 

C4 

—  [EVAL  by  RULE  12 7]  ---> 

C3 


(SUIT-LED) 

---  [EVAL  by  RULE348]  — -> 
S 


(SUIT-LED) 

---  [EVAL  by  RULE346]  — -> 

S 

(VOID  (QSO)  S) 

---  [by  RULE266]  — -> 

(CONSIDER  (VOIO  (QSO)  S)) 

(VOIO  (OSO)  S) 

---  [ELABORATE  by  RULE124]  — > 

(NOT  ( EXISTS  C5  (CARDS- IN-HAND  (QSO))  (IN-SUIT  C5  S))) 

(CARDS- IN-HANO  (QSO)) 

---  [ELABORATE  by  BULE124]  — > 

(SET-OF  C6  (CAROS)  (HAS  (QSO)  C6> ) 

(EXISTS  C6  (SET-OF  C6  (CARDS)  (HAS  (QSO)  C8))  (IN-SUIT  C5  S)) 
---  [by  RULE135]  — > 

(EXISTS  CS  (CARDS)  (ANO  [HAS  (QSO)  C5]  [IN-SUIT  C5  S])) 


(OSO) 


§D.3.  DERIV3:  Rush  the  Queen 
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I  3:#» 

|>  3 : 59 

II  3:70 

II  3:71 

II  3: 72 

II  3  73 

II  3:74 

|<  3:75 

I  3:76 

<  3:  77 

3:  78 

3:  79 

3:80 

((LEADING 

3:81 

3:82 

3:83 

3:84 

3:88 


---  [ELABORATE  by  RULE  124]  — -> 

(OWNER-QF  QS) 

(EXISTS  C5  (CARDS)  (AND  (HAS  (OWNER-OF  QS)  CS]  [IN-SUIT  C5  S])) 
---  (by  RULE347 ]  --> 

(SHOW  (AND  [HAS  (OWNER-OF  QS)  QS]  [IN-SUIT  QS  $])) 

(HAS  (OWNCR-OF  QS)  QS) 

—  [EVAL  by  RULEl]  ---> 

T 

(IN-SUIT  QS  S) 

—  [ELABORATE  by  RULE  124}  ---> 

(«  (SUIT-OF  QS)  S) 

(SUIT-OF  QS) 

---  [EVAL  by  RULE2]  — > 

S 

(•  S  S) 

---  [EVAL  by  RULE1/9]  — 

T 

(ANO  T  T) 

---  [COMPUTE  by  RULE238]  ---> 


(SHOW  T) 

—  -  [SUCCEED  by  RULE53]  — -> 

(CONSIDER  (NOT  T)) 

(NOT  T) 

---  [COMPUTE  by  RULE 236]  — > 

NIL 

(CONSIDER  NIL) 

---  [by  RULE269]  --> 

(UNTIL  (PLAYEO •  QS) 

(ACHIEVE  (AND  (PLAY  (QSO)  C3] 

[»>  (LEADING  (QSO)) 

(OR  [CAN-LEAD-HEARTS  (QSO)]  [NEQ  (SUIT-OF  C3 )  H])] 

(»>  (FOLLOWING  (QSO))  (OR  NIL  [IN-SUIT  C3  $])] 

[IN  C3  (DIFF  (CARDS)  (SET  QS))]))) 

(OR  MIL  [IN-SUIT  C3  S]) 

---  [SIMPLIFY  by  RULE176]  ---> 

(OR  [IN-SUIT  C3  SI) 

—  [SIMPLIFY  by  RULE  178]  — -> 

(IN-SUIT  C3  S) 

(»>  (LEADING  (QSO)) 

(OR  [CAN -LEAD -HEARTS  (QSO)]  [NEQ  (SUIT-OF  C3)  H])) 

---  [ASSUME  by  RULE349]  ---' 

T 

(QSO))  <-  :  (*>  NIL  IF  (•  (LEAOING  (QSO))  NIL))) 

(ACHIEVE  (AND  (PLAY  (QSO)  C3] 

T  [->  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)] 

(IN  C3  (DIFF  (CARDS)  (SET  QS))])) 

---  [by  RULE350]  ---> 

(ACHIEVE  (AND  [PLAY  (QSO)  C3]  T  (->  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)])) 

(ANO  [PLAY  (QSO)  C3)  T  [•>  (FOLLOWING  (QSO))  (IN-SUIT  C3  S)]) 
---  [SIMPLIFY  by  RULEl 1]  ---> 

(ANO  (PLAY  (QSO)  C3)  [»•*  (FOLLOWING  (QSO))  (IN-SUIT  C3  S))) 

(FOLLOWING  (QSO)) 

---  [ELABORATE  by  RULE124]  ---> 

(NOT  (LEAOING  (QSO))) 

(LEADING  (QSO)) 

---  [EVAL  by  RULE348]  ---> 

NIL 


(NOT  NIL) 

— -  [COMPUTE  by  RULE 2 36]  — -> 
T 


(->  T  (IN-SUIT  C3  S) ) 

—  [SIMPLIFY  by  RULE  12]  ---> 
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( IN-SUIT  C3  S) 


(AMO  [PLAY  (QSO)  C3J  [IN-SUIT  C3  S]) 


3:87 

[RECOGNIZE  by  RULE123]  — -> 

(PLAY-SPAOE  (QSO)) 

3:88 

(ACHIEVE  (PLAY-SPADE  (QSO) ) ) 

—  [by  RULE 351]  — > 

(ACHIEVE  (AND  [-  (LEADING  (QSO))  NIL]  £•  (SUIT-LED)  $])) 

3:89 

(■  (LEADING  (QSO))  MIL) 

— -  (SIMPLIFY  by  RULE352]  - > 

(NOT  (LEADING  (CSO))) 

3:90 

(LEADING  (QSO)) 

—  [ELABORATE  by  RULE124]  — -> 

(•  (LEADER)  (QSO)) 

3:91 

(NOT  (•  (LEAOER)  (QSO))) 

---  (by  RULE 353]  — -> 

(»  (LEADER)  ME) 

3:92 

(SUIT-LED) 

— -  [ELABORATE  by  RULE124]  ---> 

(SUIT -Of  (CARD-QF  (LEAOER))) 

3:93 

(■  (SUIT-OF  (CAHO-OF  (LEAOER)))  S) 

—  -  (RECOGNIZE  by  RULE  123]  — > 

(IN-SUIT  (CARO-OF  (LEADER))  S) 

3:94 

—  -  [RECOGNIZE  by  RULE  123 ]  — > 

(SPAOE!  (CARD-OF  (LEADER))) 

3:95 

(AND  [>  (LEADER)  ME]  [SPADE!  (CARD-OF  (LEAOER))]) 
---  (by  RULE354]  ---> 

(ANO  [>  (LEADER)  ME]  [SPADE!  (CARO-OF  HE)}) 

3:96 

(»  (LEADER)  ME) 

---  [RECOGNIZE  by  RULE123]  — > 

(LEADING  ME) 

3:97 

(ANO  [LEADING  ME]  (SPAOE!  (CARO-OF  ME)]) 

—  -  [RECOGNIZE  by  RULE123]  --> 

(LEAD-SPAOE  ME) 

[Final  axprasslon:] 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPAOE  ME))) 

(ASSUMING  (LEADING  (QSO))  ->  NIL) 

(ASSUMING  (SUIT-LED)  ->  S) 

NIL 

<51>racordfU« 

RECORD  FILE  OSK:  (DV3007  .  PZG)  CLOSED  ZO-MAR-81  21:56:38 


D.4.  DERIV4:  Decide  if  the  Queen  is  Out 


RECORD  FILE  OSK:  (OV4O07  .  PZG)  OPENED  07-OEC-SO  18:20:69 
NIL 

<42>p-11nka  nil 

(DERIV4  STARTED  Ml-APR-80  23:14:14”  --DOMAIN:  HEARTS  —PROBLEM: 
(EVAL  (OS-OUT))) 


[Initial  axprtaalon:] 

(EVAL  (QS-OUT)) 

(OS-OUT) 

4:1  ---  [ELABORATE  by  RULE124]  — > 

(OUT  QS) 

4:2  ---  [ELABORATE  by  RULE  124]  -— > 
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(EXISTS  PI  { OPPONENTS  ME)  (HAS  PI  QS) ) 

(HAS  PI  QS) 

4:3  -  [ELABORATE  by  RULE124]  -*-> 

(AT  QS  (HANO  PI)) 

4.4  ---  [ELABORATE  by  RULE124]  —  -> 

<•  (LOC  OS)  (MANO  PI)) 

(EXISTS  PI  (OPPONENTS  ME)  (-  (LOC  QS)  (HANO  PI))) 

4:8  ---  [COLLECT  by  RULE  161 ]  — > 

(EXISTS  Y1  (PROJECT  HANO  (OPPONENTS  ME))  (-  (LOC  QS)  YX ) ) 

4:6  — -  (REMOVE-QUANT  by  RULE182]  ---> 

(IN  (LOC  OS)  (PROJECT  HAW)  (OPPONENTS  ME))) 

4:7  ---  [TRY -THIS  by  RULE  169]  — > 

(NOT  (IN  (LOC  QS)  (DIFF  (RANGE  LOC)  (PROJECT  HANO  (OPPONENTS  ME))))) 

(OIFF  (RANGE  LOC)  (PROJECT  HAND  (OPPONENTS  ME))) 

>  4:0  ---  [by  RULE260]  — -> 

(CONSIDER  (DIFF  (RANGE  LOC)  (PROJECT  HAND  (OPPONENTS  ME)))) 

(RANGE  LOC) 

|  4:9  (ENUMERATE  by  RULE  163]  ---> 

(PARTITION  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

|  4:10  — -  (GENERALIZE  by  RULE  15]  ---> 

(UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 

((OISJOINT  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)) 

<-  ; 

(->  T  IF 

(*  (DISJOINT  (HANOS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  OECK  POT  HOLE)) 

T))) 

(OPPONENTS  #£) 

|  4:11  — -  [ELABORATE  by  RULE124]  — -> 

(DIFF  (PLAYERS)  (SET  ME)) 

(PROJECT  HANO  (DIFF  (PLAYERS)  (SET  ME))) 

)  4:12  ---  [DISTRIBUTE  by  RULE  170]  —  -> 

(OIFF  (PROJECT  HANO  (PLAYERS))  (PROJECT  HAND  (SET  ME))) 

(PROJECT  HANO  (SET  ME)) 

|  4:13  ---  [DISTRIBUTE  by  RULE171]  ---> 

(SET  (HAND  ME)) 

(PROJECT  HANO  (PLAYERS)) 

|  4:14  ---  [RECOGNIZE  by  RULE123]  ---> 

(HANDS  (PLAYERS)) 

(OIFF  (UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 

(OIFF  (HANOS  (PLAYERS))  (SET  (HANO  ME)))) 

|  4:15  —  [DISTRIBUTE  by  RULE  164]  ---> 

(UNION  (DIFF  (UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 
(HANOS  (PLAYERS))) 

(INTERSECT  (UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  OECK  POT  HOLE)) 
(SET  (HAND  ME)))) 

(DIFF  (UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 
(HANDS  (PLAYERS))) 

|>  4:16  ---  [SIMPLIFY  by  RULE  19]  — -> 

(SHOW  (DISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE))) 

(OISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE)) 

||  4:17  ---  [EVAL  by  RULE346]  — -> 

T 

(SHOW  T) 

|<  4:18  [SUCCEED  by  RULE34]  — -> 

(CONSIDER  (UNION  (UNION  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 
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|>  4:l» 

II  *:J0 

II  *« 

||  4:22 

II  * :M 
II  «2« 

II  «  2» 

II  *-n 

|<  4:27 

(  4;2« 

)  4:2* 

<  A\ 30 

*:3l 

*:3» 

4  33 


{ INTERSECT  (UNION  ( HANDS  (PLAYERS))  (PIUS  (PLAYERS) )  (SET  0ECX  POT  HOLE)) 
(SET  (HAND  ME))))) 

(INTERSECT  (UNION  (HANDS  (PLAYERS) )  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 
(SET  (HAND  ME))) 

—  (by  AULE268]  — > 

(CONSIDER  (INTERSECT  (UNION  (HANOS  (PLAYERS))  (PRES  (PLAYERS))  (.SET  DECK  POT  HOLE)) 
(SET  (HAND  ME)))) 


(INTERSECT  (UNION  (HANDS  (PLAYERS))  (PRES  (PLAYERS))  (SET  OECK  POT  HOLE)) 
(SET  (HAND  ME))) 

—  -  (UNO RACKET  by  RULE  166] 

(IF  (IN  (HANO  ME) 

(UNION  (HANOS  (PLAYERS))  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE))) 
l SET  (HANO  ME)) 

NIL) 


(IN  (HANO  ME) 

(UNION  (HANDS  (PLAYERS))  (PILES  (PLAYERS))  (SET  OECK  POT  HOLE))) 
[DISTRIBUTE  by  RULE284]  — > 

(OR  (IN  (HANO  ME)  (HANDS  (PLAYERS))] 

(IN  (HANO  ME)  (PRES  (PLAYERS))] 

(IN  (HANO  ME)  (SET  OECK  POT  HOLE)]) 

(HANDS  (PLAYERS)) 

—  (ELABORATE  by  RULE124]  ---> 

(PROJECT  HAND  (PLAYERS)) 

( IN  (HANO  ME)  (PROJECT  HANO  (PLAYERS))) 

(REMOVE-QUANT  by  RULE  172]  *— > 

(IN  ME  (PLAYERS)) 

—  -  [EVAL  by  RULE173]  ---> 

T 

(OR  T  [IN  (HAND  HE)  (PILES  (PLAYERS))) 

(IN  (HAND  ME)  (SET  OECK  POT  HOLE))) 

[EVAL  by  RULE  184] 


(If  T  (SET  (HANO  ME))  NR) 

(SIMPLIFY  by  RULE185]  — *> 
(SET  (HANO  ME)) 


(CONSIDER  (SET  (HANO  ME))) 

---  (by  RULE269]  — > 

(CONSIDER  (UNION  (UNION  /PILES  (PLAYERS))  (SET  DECK  POT  HOLE)) 

(SET  (HAND  ME)))) 

(UNION  (UNION  (PRES  (PLAYERS))  (SET  DECK  POT  HOLE)) 

(SET  (HAND  ME))) 

—  -  (SIMPLIFY  by  RULE  17  7]  ---> 

(UNION  (PILES  (PLAYERS))  (SET  DECK  POT  HOLE)  (SET  (HANO  ME))) 
---  (SIMPLIFY  by  RULE  187 ]  —•) 

(UNION  (SET  OECK  POT  HOLE  (HAND  ME))  (PILES  (PLAYERS))) 

(CONSIDER  (UNION  (SET  OECK  POT  HOLE  (HANO  ME))  (PILES  (PLAYERS)))) 

(by  RULE269]  — > 

(EVAL  (NOT  (IN  (IOC  QS) 

(UNION  (SET  DECK  POT  HOLE  (HANO  ME))  (PRES  (PLAYERS) ) ) ) )) 

(IN  (LOC  OS) 

(UNION  (SET  OECK  POT  HOLE  (HANO  ME))  (PRES  (PLAYERS)))) 
(DISTRIBUTE  by  RULE264]  ---> 

(OR  (IN  (LOC  OS)  (SET  DECK  POT  HOLE  (HANO  ME))] 

(IN  (LOC  QS)  (PRES  (PLAYERS))]) 

(IN  (LOC  OS)  (SET  DECK  POT  HOLE  (HANO  ME))) 

(DISTRIBUTE  by  RULE  102) 

(OR  [•  HOC  OS)  DECK) 

CM  IOC  OS)  POT) 

[*  (LOC  OS)  HOLE] 

[-  (LOC  QS)  (HANO  ME)]) 

(OR  (OR  (*  (LOC  QS)  OECK] 

(*  (LOC  QS)  POT] 

[•  (LOC  QS)  HOLE] 

(•  (LOC  QS)  (HANO  ME)]] 

(IN  (LOC  OS)  (PRES  (PLAYERS))]) 

---  (SIMPLIFY  by  RULE177]  — > 
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4:34 


4:35 


4:35 


4.3! 


4.35 


4.39 


4:40 


4:41 


4:  42 


>  4:43 


|  4:44 

|  4:45 

|  4:48 
|  1:47 


|  4:40 


|  4:49 


(OK  [■  (LOC  OS)  0£CX] 

(>  (LOC  OS)  POT] 

[*  (LOC  OS)  HOl£] 

[•  (LOC  OS)  (HAND  ME)] 

[IN  (LOC  OS)  (PILES  (PLAYERS) ) ]) 

(■  (LOC  OS)  0£CA) 

---  (RECOGNIZE  5 y  *UL£  133]  ---> 

(AT  OS  0£CK) 

(■  (LOC  OS)  POT) 

---  [RECOGNIZE  by  RULE123]  — > 

(AT  OS  POT) 

(«  (LOC  OS)  HOLE) 

---  [RECOGNIZE  by  RULE  123]  — -> 

(AT  OS  HOLE) 

(>  (LOC  OS)  (HAND  ME)) 

---  (RECOGNIZE  by  RULE123]  --- > 

(AT  OS  (HAND  ME)) 

(AT  OS  OECA) 

---  [EVAL  by  RULE  130] 

NIL 

(OR  NIL  [AT  OS  POT] 

[AT  OS  HOLE] 

[At  OS  (HANO  ME)] 

(IN  (LOC  OS)  (PILES  (PLAYERS))]) 

---  (SIMPLIFY  by  RULE17B]  — -> 

(OR  (AT  OS  POT] 

[AT  OS  HOLE] 

(AT  OS  (HAND  ME)) 

(IN  (LOC  OS)  (PILES  (PLAYERS))]) 

(AT  OS  POT) 

---  (RECOGNIZE  by  RULE123]  ---> 

(IN-POT  OS) 

(AT  OS  (HANO  ME)) 

---  (RECOGNIZE  by  RULE123]  ---> 

(HAS  ME  OS) 

[RECOGNIZE  by  RULE1Z3]  — > 

(HAS-ME  OS) 

(IN  (LOC  OS)  (PILES  (PLAYERS))) 

---  [by  RULEZ88]  ---> 

(CONSIDER  (IN  (LOC  OS)  (PILES  (PLAYERS)))) 

(PILES  (PLAYERS)) 

—  -  (ELABORATE  by  RULE  124]  ---> 

(PROJECT  PILE  (PLAYERS)) 

(IN  (LOC  OS)  (PROJECT  PILE  (PLAYERS))) 

---  (by  RULE14]  — > 

(EXISTS  P3  (PLAYERS)  (*  (LOC  OS)  (PILE  P3))) 

(■  (LOC  OS)  (PUE  P3 ) ) 

-  [RECOGNIZE  by  RULE123]  ---> 

(AT  OS  (PILE  P3 ) ) 

—  (by  RULEJ56]  --> 

(OR  [MAS-OURING  (CURRENT  ROUND- IN- PROGRESS) 

(CAUSE  (AT  OS  (PILE  P3)))] 

[BEFORE  (CURRENT  ROUND- IN-PROCRESS )  (»T  OS  (PILE  P3))J) 

(BEFORE  (CURRENT  ROUND-IN-PROCRESS)  (AT  OS  (PILE  P3))) 
---  [EVAL  by  RULE357]  — > 

NIL 

(OR  [MAS-OURING  (CURRENT  ROUND- IN- PROGRESS) 

(CAUSE  (AT  OS  (PILE  P3 ) ) ) ] 

NIL) 

...  [SIMPLIFY  by  RULE l 78]  ---> 

(OR  [MAS-OURING  (CURRENT  ROUND-IN-PROGRESS) 

(CAUSE  (AT  OS  (PILE  P3)))]) 


|  4:50 


---  (SIMPLIFY  by  RULE  178]  ---> 
(MAS-OURING  (CURRENT  ROUND-IN-PROGRESS) 


{TAKE  P3  OS) 


(NAS-DURING  (CURRENT  ROUND* IN- PROGRESS )  (TAKE  P3  QS ) ) 
|  4: S3  [RECOGNIZE  by  RULE  123]  ---> 

(TOOK  P3  QS) 

(EXISTS  P3  (PLAYERS)  (TOOK  P3  QS)) 

|  4:54  ---  [RECOGNIZE  by  RULE  123]  — > 

(TAKEN  QS) 

(CONSIDER  (TAKEN  QS)) 

<  4:56  ---  [by  RULE269]  ---> 

(EVAL  (NOT  (OR  [IN-PQT  QS]  [AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  QS]))) 

[Final  •uprasslon : ] 

(EVAL  (NOT  (OR  [IN-POT  QS]  [AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  QS]))) 

(ASSUMING  (DISJOINT  (HANDS  (PLAYERS)) 

(PILES  (PLAYERS)) 

(SET  DECK  POT  HOLE))) 

NIL 

<43>r«cordf 11a 

RECORD  FILE  DSK;  (DV4007  PZG)  CLOSED  07-OEC-ftO  18:25:03 


D.5.  DERIV5:  Flush  the  Queen  without  Taking  it 


RECORD  FILE  OSK:  (DV5007  .  PZG)  OPENED  07-DEC-80  18:25:31 
NIL 

<63>p- 1  inks  nil 

(DERIV5  STARTED  "14-APR-80  22:42:30"  --DOMAIN:  HEARTS  --PROBLEM: 

(ANO  [ACHIEVE  (FLUSH  QS)]  [AVOID  (TAKE  ME  QS)  (TRICK)])) 


[Initial  axprasslon:] 

(ANO  [ACHIEVE  (FLUSH  QS)]  [AVOIO  (TAKE  ME  OS)  (TRICK)]) 

(ACHIEVE  (FLUSH  QS)) 

5:1  ---  [REOUCE  by  RULE30I]  —  > 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAO-SPAOE  ME))) 

(AVOIO  (TAKE  ME  QS)  (TRICK)) 

5:2  ---  [ELABORATE  by  RULE124]  ---> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS ) ) ) ) 

(ANO  [UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAO-SPAOE  ME))] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS)))]) 

5.3  — -  [by  RULE 359]  ---> 

(UNTIL  (PLAYED!  QS) 

(ANO  [ACHIEVE  (LEAO-SPAOE  ME)] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS)))])) 

(AND  [ACHIEVE  (LEAO-SPAOE  ME)] 

[ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE  ME  QS)))]) 

5:4  ---  [COLLECT  by  RULE360]  ---» 

(ACHIEVE  (ANO  [LIAO-SPAOE  ME]  [NOT  (DURING  (TRICK)  (TAKE  ME  QS))])) 

(OURING  (TRICK)  (TAKE  ME  QS)) 

>  5:6  ---  (by  RULE 26ft]  — > 

(CONSIDER  (DURING  (TR(CX)  (TAKE  ME  QS))) 

(TRICK) 

|  5:9  -  [ELABORATE  by  RULE 124  ]  — > 

(SCENARIO  (EACH  Pi  (PLAYERS)  (PLAY-CARD  Pi))  + 

(TAKE-TRICK  ( TRICK-WINNER) ) ) 


« 
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1  5:7 


1  3:5 

|  5:9 

t  5: 10 


|  5:11 


|  5:12 


|  5:13 


\  5:14 

|  5:15 

)  5:16 


(DURING  (SCENARIO  (EACH  Pi  (PLAYERS)  (PLAY-CARD  Pi)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE  ME  QS) ) 

—  [DISTRIBUTE  by  RULE284]  — > 

(OR  (DURING  (EACH  Pi  (PLAYERS)  (PLAY-CARD  Pt))  (TAKE  Ml  QS)] 
[OURING  ( TAKE-  TRICK  (  TRICK- WINNER) )  (TAKE  ME  <?$))) 

(DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  Pi))  (TAKE  ME  QS)) 

—  (COMPUTE  by  RULE57]  ---> 

NIL 

(OR  NIL  [DURING  (TAKE  TRICK  (TRICK-WINNER) )  (TAKE  ME  QS)]) 

---  (SIMPLIFY  by  RULE341 ]  ---> 

(OURING  (TAKE-TRICK  (TRICK -WINNER) )  (TAKE  ME  Q$)) 

(TAKE-TRICK  (TRlCX-WlNNtR) ) 

---  [ELABORATE  by  RULEI24]  ---> 

(EACH  Cl  (CARDS-PLAYED)  (TAKE  ( TRICK- WINNER)  Cl)) 

(OURING  (EACH  Cl  (CAROS-PLAYED)  (TAKE  (TRICK-WINNER)  Cl)) 

(TAKE  ME  QS) ) 

-  [COLLECT  by  RULE58]  ---> 

(EXISTS  Cl  (CARDS-PLAYED) 

(OURING  (TAKE  (TRICK-WINNER)  Cl)  (TAKE  ME  OS))) 

(DURING  (TAKE  (TRICK-WINNER)  Cl)  (TAKE  ME  OS)) 

— •  [DISTRIBUTE  by  RULE43]  ---> 

(AND  (*  (TRICK  WINNER)  ME]  [-  Cl  QS]) 

•(EXISTS  Cl  (CARDS-PLAYED)  (ANO  [«  (TRICK-WINNER)  ME]  [•  Cl  OS])) 
---  [REMOVE-QUANT  by  RULE59]  ---> 

(AMO  [IN  QS  (CAROS-PLAYEO)]  [«  ( TRICK-WINNER)  ME]) 

(TRICK-WINNER) 

---  [ELABORATE  by  RULE124]  ---> 

(PUYER-OF  (WINNING-CARD)) 

(«=  (PlAYER-OF  (WINNING-CARD))  ME) 

---  [LEMMA  by  RULE  146 ]  ---> 

(-  ( CARD-Of  ME)  (WINNING  CARD)) 

(WINNING-CARD) 

---  [ELABORATE  by  RULE  124 ]  ---> 

(HIGHEST-IN-SUIT-LEO  (CAROS-PLAYED)) 


|  5.17  ---  [ELABORATE  by  RULE124]  — > 

(HIGHEST  (CARDS- IN- SUIT- LED  (CARDS-PLAYED))) 


J  5:16  ---  [ELABORATE  by  RULE  124]  ---> 

(THE  C2  (CAROS- IN- SUl T -  LED  (CAROS-PLAYED) ) 

(FORALL  XI  (CARDS-IN-SUIT-LED  (CARDS-PLAYED) ) 
(NOT  (HIGHER  XI  C2 ) ) )  ) 


(«  (CARO-0F  ME) 

(The  C2  (Cards-in-suit-led  (CARds-playeo)) 

(FORALL  XI  (CARDS-IN-SUIT-LED  (CARDS-PLAYED)) 

(NOT  (HIGHER  XI  C2))))) 

|  5:19  ---  [UWBRACXET  by  RULEB4]  ---> 

(AND  [IN  (CARD-OF  ME)  (CARDS-IN-SUIT-LED  (CARDS-PLhYED) ) ] 

[FORALL  XI  (CAROS-IN-SUIT-LED  (CAROS-PLAYED)) 

(NOT  (HIGHER  XI  (CARD-OF  ME)))]) 

(CAROS- IN-SUIT-LED  (CARDS-PLAYED)) 

)  5:20  —  [ELABORATE  by  RULE124]  ---> 

(FILTER  (CARDS-PLAYED)  IN-SUIT-LED) 

(IN  (CARD-OF  ME)  (FILTER  (CARDS-PLAYED)  IN-SUIT-LEO) ) 

)  5:21  ---  [ELABORATE  by  RULE361]  — > 

(ANO  [IN  (CARO-OF  ME)  (CAROS-PLAYED)]  [IN-SUIT-LED  (CARD-OF  ME)]) 

(CAROS-PLAYED) 

|  5:22  ---  [EUBORATE  by  RULE  124 ]  ---> 

(PROJECT  CARD-OF  (PLAYERS)) 

(IN  (CARO-OF  ME)  (PROJECT  CARO-OF  (PUYCRS))) 

)  5:23  —  (REMOVE-QUANT  by  RULE  172]  — > 

(IN  ME  (PUYERS)) 


l  3:24 


T 


[EVAL  by  RULE  1 73]  ---> 
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|  5:25 
|  5:25 

|  5:27 

<  5:28 

5:29 

5  30 

5:31 

5:32 

5:33 

5:34 

5:36 

>  5:36 

|  5:37 


(AMD  T  [IN-SUIT-LED  (CARD-OF  HE)]) 

---  (SIMPLIFY  by  RULE341]  — > 

(IN-SUIT-LED  (CARD-OF  ME)) 

—  [ELABORATE  by  RUIE124]  ---> 

(»  (SUIT -OF  (CARD-OF  Ml))  <  SUIT-LEO) ) 

(SUIT-LED) 

---  [ELABORATE  by  RULE124]  ---> 

(SUIT-OF  (CARD-OF  ( LEAOER) ) ) 

(CONSIDER  (ANO  [IN  OS  (CARDSPLAYED) ] 

[AND  [«  (SUIT-OF  (CARD-OF  ME))  (SUIT-OF  (CARD-OF  (LEAOER)))] 
[FORALL  XI  (CARDS- IN-SUIT-LED  (CARDS-PLAYEO) ) 

(NOT  (HIGHER  Xl  (CARD-OF  ME)))]])) 

—  -  [by  RULE269]  — -> 

(UNTIL  (PLAYED!  QS) 

(ACHIEVE  (AND  [LEAD-SPADE  ME] 

[NOT  (ANO  (IN  OS  (CARDS-PLAYEO) ] 

[AMD  (=  (SUIT-OF  (CARD-OF  ME))  (SUIT-OF  (CARD-OF  (LEADER)))] 
[FORALL  XI  (CARDS' IN' SUIT- LED  ( CARDS  -  PLAYED) ) 

(NOT  (HIGHER  Xi  (CARO-OF  ME)))]])]))) 

(LEAO-SPADE  ME) 

---  [ELABORATE  by  RULE  124]  ---> 

(ANO  [LEAOING  ME]  [SPADE!  (CARD-OF  ME)]) 

(LEADING  ME) 

---  [ELABORATE  by  RULE  124]  ---> 

(■  (LEAOER)  ME) 

(ANO  [AND  [=  (LEAOER)  ME]  [SPADE!  (CARO-OF  ME)]] 

[NOT  (AND  [IN  QS  (CARDSPLAYED) ] 

[AND  (•  (SUIT-OF  (CARO-OF  ME))  (SUIT-OF  (CARO-OF  (LEADER)))] 
(FORALL  XI  (CARDS- IN- SUIT-LED  (CARDS-PLAYEO)) 

(NOT  (HIGHER  Xl  (CARO-OF  ME)))]])]) 

---  [SIMPLIFY  by  RULE177]  ---> 

(AND  [•  (LEAOER)  ME] 

[SPADE!  (CARD-OF  ME)] 

(HOT  (ANO  (IN  QS  ( CARDS-PLAYEO )] 

[AND  (»  (SUIT-OF  (CARD-OF  ME))  (SUIT-OF  (CARO-OF  (LEADER)))] 
[FORALL  XI  (CARDS- IN- SUIT-LED  ( CARDS- PLAYED) ) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))]])]) 


---  [by  RULE354]  ---> 

(AND  [»  (LEADER)  ME] 

[SPADE!  (CARO-OF  ME)] 

[NOT  (AND  [IN  QS  ( CAROS- PLAYED) ] 

[ANO  [--  (SUIT-OF  (CARD-OF  ME))  (SUIT-OF  (CARO-OF  ME))] 
(FORALL  XI  (CARDS-IN-SUIT-IED  (CAROS- PLAYED) ) 

(NOT  (HIGHER  Xl  (CARO-OF  ME)))]])]) 

(*  (SUIT-OF  (CARO-OF  ME))  (SUIT-OF  (CARO-OF  ME))) 

---  [EVAl  by  RULE  179]  ---> 

T 

(ANO  r 

(FORALL  Xl  (CAROS- IN -SUIT- LED  (CAROS- PLAYED) ) 

(NOT  (HIGHER  Xl  (CARD-OF  ME)))]) 

---  [SIMPLIFY  by  RULE341]  ---> 

(FORALL  Xl  (CAROS- IN-SUIT-LEO  (CAROS-PLAYEO) ) 

(NOT  (HIGHER  Xl  (CARO-OF  ME)))) 

(NOT  (ANO  (IN  QS  (CARDS-PLAYEO)] 

[FORALL  Xl  (CAROS- IN-SUIT-LEO  (CAROS-PLAYED) ) 

(NOT  (HIGHER  Xl  (CARO-OF  ME)))])) 

---  [by  RULE 109]  ---> 

(->  (ANO  [IN  OS  (CAROS-PLAYEO)]) 

(NOT  (NOT  (HIGHER  (FINO-ELT  (CARQS- IN-St*T-LEO  (CAROS-PLAYEO))) 
(CARO-OF  ME))))) 


—  [by  RULE285]  — -> 

(CONSIDER  (O  (ANO  [IN  QS  (CAROS-PLAYEO)]) 

(NOT  (NOT  (HIGHER  (FINO-ELT  (CAROS- IN-SUIT-LEO  (CAROS-PLAYED) ) ) 
(CARO-OF  ME)))))) 

(ANO  [IN  OS  (CARDS-PLAYEO)]) 

—  [SIMPLIFY  by  RULE176]  ---> 

(IN  OS  (CARDS-PLAYEO)) 


(NOT  (NOT  (HIGHER  (FINO-ELT  (CAROS- IN-SUIT-LED  (CAROS-PLAYEO))) 


t 


§D.5.  DERIV5:  Flush  the  Queen  without  Taking  it 


443 


|  6:38 

|>  5:39 

M  5:40 

II  5:41 

II  5:« 


(CARO-0F  «C ) ) ) ) 

-  [SIMPLIFY  by  RULE88]  ---> 

[HIGHER  (FINOElT  (CAROS- 18 -SUIT -LED  (CAROS-PLAYED)) ) 
(CARO'OF  ME)) 

(FIMO-ELT  (CARDS-m-SUIT-LEO  (CAROS-PLAYED))) 
---  [by  RULE84]  ---> 

(SHOW  (IN  OS  (CARDS- IM-SUIT-LED  (CAROS-PlAYED) ) )) 

(CARDS- IM-SUIT-LED  (CAROS-PLAYED)) 

---  [ELABORATE  by  RULE  124]  -— > 

(FILTER  (CAROS-PLAYED)  IM-SUIT-LED) 

(IN  OS  (FILTER  (CAROS-PLAYED)  IM-SUIT-LED)) 
(ELABORATE  by  RULE36I]  ---> 

(AMD  (IM  OS  (CAROS-PLAYED)]  [IM-SUIT-LED  QSJ) 

(IM  QS  (CAROS-PLAYED)) 

---  [REDUCE  by  RULE301]  — 

T 


(ANO  T  [IM-SUIT-LED  QS]) 

ft  6-43  ---  [SIMPLIFY  by  RULE341 }  — -> 

( IN- SUIT-LED  OS) 

||  5:44  —  [ELABORATE  by  RULE124T  — > 

(»  ( SUIT -OF  QS)  (SUIT-LED)) 

(SUIT-OF  QS) 

||  5:45  [EVAL  by  RULE2]  ---> 

S 

(SUIT-LED) 

||  5:4ft  ---  [REDUCE  by  RULE301]  ---> 

(SUIT-OF  (CARD-OF  ME)) 

|)  5:4?  ---  [REOUCE  by  RULE301]  — > 

S 

C  S  S) 

)J  5:48  ---  [EVAL  by  RULE  179 ]  — > 

T 

(SHOM  T) 

|<  5:49  ---  [SUCCEED  by  RULE34]  ---> 

(CONSIDER  (•>  (IM  OS  (CAROS-PLAYED))  (HIGHER  QS  (CARD-OF  ME)))) 

(O  (IM  QS  (CAROS-PLAYED))  (HIGHER  QS  (CARD-OF  ME))) 

|  5:50  ---  [by  RULE  157 ]  — > 

(HIGHER  OS  (CARO-OF  ME)) 

(CONSIDER  (HIGHER  QS  (CARO-OF  ME))) 

<  5:51  ---  [by  RULE269]  — -> 

(UMTU  (PLAYED!  OS) 

(ACHIEVE  (AMO  [*  (LEAOER)  ME] 

[SPAOE!  (CARO-OF  ME)] 

[HIGHER  QS  (CARO-OF  ME)]))) 

(•  (LEAOER)  ME) 

5:52  ---  [RECOGNIZE  by  RULE  123]  — > 

(LEADING  ME) 

(AMO  [LEAOING  ME]  [SPADE!  (CARO-OF  ME)]  [HIGHER  QS  (CARD-Of  ME)]) 
6:53  ---  [RECOGNIZE  by  RULE  123]  —  > 

(LEAO- SAFE -SPADE  ME) 

[Ftn»1  expression:] 

(UNTIL  (PLAYED!  OS)  (ACHIEVE  (LEAD-SAFE-SPAOE  M£))) 

NIL 

<84>recordf11e 

RECORD  FILE  OSlt;  (0V5 00?  .  PZG)  CLOSED  07-DEC-80  18:29:02 


% 
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D.6.  DERIV6:  Avoid  Taking  Points  (Play  a  Low  Card) 


RECORO  PILE  OSK.:  (OV6DQ7  .  PZG)  OPENED  07-0EC-8Q  18:29:28 
MIL 

<72>p-l Inks  nil 

(OERIV6  STARTED  "21-APR-80  18:33. 13"  --DOMAIN:  HEARTS  --PROBLEM: 
( AVOID- TAKING -POINTS  (TRICK))) 


[Initial  axpraiston:] 

(A VO ID- TAKING -POINTS  (TRICK)) 

6:1  — -  [ELABORATE  by  RULE  124 ]  ---> 

(AVOID  (TAKE-POINTS  ME)  (TRICK)) 

6:2  ---  (ELABORATE  by  RULE124]  — -> 

(ACHIEVE  (NOT  (DURING  (TRICK)  (TAKE-POINTS  ME)))) 

(TRICK) 

6:3  — -  (ELABORATE  by  RULE  124]  — -> 

(SCENARIO  (EACH  Pi  (PLAYERS)  (PLAY-CARO  PI)) 

(TAKE-TRICK  ( TRICK-WINNER) ) ) 

(DURING  (SCENARIO  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI)) 

(TAKE-TRICK  (TRICK-WINNER))) 

(TAKE-POINTS  ME)) 

8:4  ---  [DISTRIBUTE  by  RULE284]  ---> 

(OR  [DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)] 

(DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE-POINTS  ME)]) 

(DURING  (EACH  PI  (PLAYERS)  (PLAY-CARD  PI))  (TAKE-POINTS  ME)) 

65  ---  [COMPUTE  by  RULE57]  — -> 

NIL 

(OR  NIL  [DURING  (TAKE-TRICK  (TRICK-WINNER))  (TAKE-POINTS  ME)]) 

6:6  ---  [SIMPLIFY  by  RULE341]  — -> 

(OURING  (TAKE-TRICK  ( TRICK-WI NNER) )  (TAKE-POINTS  ME)) 

(TAKE-POINTS  ME) 

6:7  ---  [ELABORATE  by  RULE124]  —  -> 

(FOR-SOME  Cl  (POIMT-CAROS)  (TAKE  ME  Cl)) 

(TAKE-TRICK  (TRICK-WINNER)) 

6:8  — -  [ELABORATE  by  RULE124]  — -> 

(EACH  C3  (CARDS-PLAYED)  (TAKE  (TRICK-WINNER)  C3 ) ) 

(DURING  (EACH  C3  ( CAROS-PLAYED)  (TAKE  (TRICK-WINNER)  C3)) 

(FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl))) 

6:9  ---  [COLLECT  by  RULE58]  — -> 

(EXISTS  C3  (CAROS-PLAYED) 

(DURING  (TAKE  (TRICK-WINNER)  C3) 

(FOR-SOME  Cl  (POINT-CARDS)  (TAKE  ME  Cl)))) 

(DURING  (TAKE  (TRICK-WINNER)  C3) 

(FOR-SOME  Cl  (POINT-CAROS)  (TAKE  ME  Cl))) 

8:10  ---  [COLLECT  by  RULE100]  ---> 

(EXISTS  Cl  (POINT-CAROS) 

(DURING  (TAKE  ( TRICK-WINNER)  C3)  (TAKE  ME  Cl))) 

(DURING  (TAKE  ( TRICK- WINNER)  C3)  (TAKE  ME  Cl)) 

6:11  —  [DISTRIBUTE  by  RULE43]  — -> 

(ANO  [»  (TRICK-WINNER)  ME]  [■  C3  Cl]) 

(EXISTS  Cl  (POINT-CAROS)  (AND  [«  (TRICK-WINNER)  ME]  [»  C3  Cl])) 
6:12  ---  [REMOVE-QUANT  by  RULE59]  ---> 

(AND  [IN  C3  (POINT-CAROS)]  [•  (TRICK-WINNER)  ME]) 

(EXISTS  C3  (CAROS-PLAYED) 

(AMO  [IN  C3  (POINT-CARDS)]  [»  (TRICK-WINNER)  ME])) 

6:13  ---  [SIMPLIFY-QUANT  by  RULE  108]  — -> 

(ANO  [■  (TRICK-WINNER)  ME] 

[EXISTS  C3  (CAROS-PLAYED)  (ANO  [IN  C3  (POINT-CARDS)])]) 


6:14 


(AHO  [III  C3  (POINT-CARDS)]) 

---  [SIMPLIFY  by  RULE  178]  — > 
(IN  C3  (POINT-CAROS)) 
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9:16 

6: 16 

>  8:17 

|  6:18 

<  6:  19 

6:20 

6:21 

6:22 

>6:23 

|  6:24 

1  6:25 

|  6:26 

|  6:27 

|  6:28 

|  6:29 
|  6:30 
|  6:31 

|  6:32 

|  6:33 


( POINT-CARDS) 

—  [ ELABORATE  by  RULE  124]  ---> 

(SET-OF  C4  (CAROS)  (HAS-POINTS  C4 ) ) 

(IN  C3  (SET-OF  C4  (CAROS)  (HAS-POINTS  C4) ) ) 

—  [REMOVE -QUANT  by  RULE10]  — > 

(AND  [IN  C3  (CAROS)]  [HAS-POINTS  C3]) 

(EXISTS  C3  (CAROS-PLAYEO)  (ANO  [IN  C3  (CAROS)]  [HAS-POINTS  C3])) 
---  [SIMPLIFY-QUANT  by  RULE362]  — > 

(SHOW  ( SUBSET  (CARDS-PIAYED)  (CARDS))) 

(SUBSET  (CAROS-PLAYEO)  (CARDS)) 

---  [FACT  by  RULE363]  — -> 


(SHOW  T) 

—  -  [SUCCEED  by  RULE34]  — -> 

(ACHIEVE  (NOT  (AND  [-  ( TRICK- WINNER)  ME] 

[EXISTS  C3  (CAROS-PLAYEO)  (AND  (HAS-POINTS  C3))]))) 

(AND  [HAS-POINTS  C3]) 

---  [SIMPLIFY  by  RULE178]  — > 

(HAS-POINTS  C3) 

(EXISTS  C3  (CAROS-PLAYED)  (HAS-POINTS  C3)) 

---  [RECOGNIZE  by  RULE  123]  — > 

(HAVE-POINTS  (CAROS-PLAYEO)) 

—  -  [RECOGNIZE  by  RULE123]  — > 

(TRICK-HAS-POINTS) 

(*  (TRICK-WINNER)  ME) 

---  [by  RULE268]  -~> 

(CONSIDER  (*  (TRICK-WINNER)  ME)) 

(TRICK-WINNER) 

---  [ELABORATE  by  RULE124]  ---> 

(PLAYER-OF  (WINNING-CARD)) 

---  [ELABORATE  by  RULE124]  — > 

(THE  P2  (PLAYERS)  (»  (CARO-OF  P2)  (WINNING-CARD))) 

(»  (THE  P2  (PLAYERS)  (*  (CARO-OF  P2)  (WINNING-CARD) ) )  ME) 

---  [REMOVE-QUANT  by  RULE131]  — > 

(AND  [IN  ME  (PLAYERS)]  [«  (CARO-OF  ME)  ( WINNING-CARD) ] ) 

(IN  ME  (PLAYERS)) 

---  [FACT  by  RULE  173]  — > 

T 

(ANO  T  [=  (CARO-OF  ME)  (WINNING-CARO) ]) 

---  [SIMPLIFY  by  RULE341 ]  ---> 

(»  (CARO-OF  ME)  (WINNING-CARO)) 

(WINNING-CARD) 

---  [ELABORATE  by  RULE124]  — -> 

(HIGHEST- IN- SUIT -LEO  (CAROS-PLAYEO)) 

— -  [ELABORATE  by  RULEI24]  ---> 

(HIGHEST  (CAROS- IN- SUIT- LEO  (CAROS-PLAYEO))) 

---  [ELABORATE  by  RULE  124]  ---> 

(THE  C5  (CAROS- IN -SUIT -LEO  (CAROS-PLAYED)) 

(FORALL  XI  (CAROS- IN- SUIT -LEO  (CAROS-PLAYEO)) 

(NOT  (HIGHER  XI  CS)))) 

(■  (CARO-OF  ME) 

(THE  C5  (CAROS- IN- SUIT- LEO  (CAROS-PLAYED) ) 

(FORALL  XI  (CAROS- IN-SUIT-LED  (CAROS-PLAYED) ) 

(NOT  (HIGHER  XI  C5))))) 

—  [REMOVE-QUANT  by  RULE64]  ---> 

(ANO  [IN  (CARO-OF  ME)  (CAROS- IN-SUIT-LED  (CAROS-PLAYED))] 

[FORALL  XI  (CAROS- IN-SUIT-LED  (CAROS-PLAYEO)) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))]) 

(IN  (CARD-OF  ME)  (CAROS- IN-SUIT-LED  (CAROS-PLAYEO))) 

---  [by  RULE  149 ]  — -> 

(ANO  [IN-SUIT-LED  (CARO-OF  ME)]  [IN  (CARO-OF  ME)  (CAROS-PLAYED)]) 
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t  6:34 

I  6:36 
|  6:36 

|  6:37 

<6:36 

6:39 

6:40 

6:41 

>  6:44 

|  6:45 

t  6:46 

|>  6:47 
(CAROl  < 

II  «:4« 

|<  6:49 

|  6:50 


(CAROS-PLAYED) 

---  [ELABORATE  by  RUIE124]  — -> 

(PROJECT  CARO-QF  (PLAYERS) J 

( tM  (CARD-OF  ME)  (PROJECT  CARO-OF  (PLAYERS))) 
*'■  (REMOVE -QUART  by  RULE  172}  — > 

( 1M  ME  (PLAYERS)) 

— -  [FACT  by  RUIE173]  — > 

T 

(ANO  [ IN-SUIT-LED  (CARO-OF  ME)}  T) 

---  [SIMPLIFY  by  RULE343}  — > 

(IN-SUIT-LED  (CARO-OF  ME)) 

(CORSIOER  (AMO  [IN-SUIT-LED  (CARO-OF  ME)} 

[FORALL  XI  (CAROS- IN-SUIT-LED  (CAROS'PLAYEO) ) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))})) 

---  [by  RULE 2 69]  ---> 

(ACHIEVE  (MOT  (AMO  [AND  [IN-SUIT-LED  (CARO-OF  ME)} 

[FORALL  XI  (CARDS-IN- SUIT-LED  (CAROS-PLAYED) ) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))]} 

[TRICK- HAS -POINTS] ) ) ) 

(AND  [AND  [IN-SUIT-LED  (CARO-OF  ME)] 

[FORALL  XI  (CAROS- IN-SUIT-LEO  (CAROS- PLAYED) ) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))]} 

(TRICK -HAS -POINTS} ) 

—  [SIMPLIFY  by  RULE  177 }  — -> 

(AMO  [INSUIT-LEO  (CARO-OF  ME)] 

[FORALL  XI  (CAR0S-IM-SUir-l£0  (CAROS-PLAYED) ) 

(MOT  (HIGHER  XI  (CARO-Qf  ME)))] 

[TRICK-HAS -POINTS] ) 

(NOT  (AMO  [IM-SUIT-LCO  (CARQ-OF  ME)] 

(FORALL  XI  (CAROS-IN-SUIT-LED  (CAROS-PLAYED)) 

(NOT  (HIGHER  XI  (CARO-OF  ME)))] 

(TRICK-HAS  POINTS])) 

---  [by  RULE t09 ]  ---> 

(*>  (AND  [IN-SUIT-LED  (CARD-OF  ME)]  [TRICK-HAS-PQINTS] ) 

(NOT  (NOT  (HIGHER  (FIND-ELT  (CARDS- IN-SUIT-LEO  (CARDS-PLAYEO) ) ) 
(CARO-OF  ME))))) 

(NOT  (NOT  (HIGHER  (FIND-ELT  (CAROS-IN-SUIT-LED  (CAROS-PLAYED))) 
(CARO-OF  ME)))) 

---  [SIMPLIFY  by  RULE88]  ---> 

(HIGHER  (FIMO-ELT  (CAROS-IN-SUIT-LED  (CAROS-PLAYED) ) ) 

(CARD-OF  ME)) 

---  (TRY-THIS  by  RULE 142 ]  ---) 

(SHOW  (AMO  [IN  CAR01  (CAROS- IN -SUIT -LEO  (CAROS'PLAYEO))] 

[HIGHER  CARO  1  (CARO-OF  ME)])) 

(IN  CAR01  (CAROS* IN-SUIT-LED  (CAROS-PLAYED) ) ) 

---  [by  RULE  149]  ---> 

(AND  [IN-SUIT-LEO  CAROl]  [IN  CAROl  (CAROS-PLAYED)]) 
(CAROS-PLAYED) 

---  [ELABORATE  by  RULE124]  — > 

(PROJECT  CARO-OF  (PLAYERS)) 

(IN  CAROl  (PROJECT  CARD-OF  (PLAYERS))) 

--'  [by  RULE3B4]  ---> 

(SHOW  (IN  (LEADER)  (PLAYERS))) 

B I  NO  I MG  :  OK) 


(IN  (LEADER)  (PLAYERS)) 

---  [FACT  by  RULE385]  — -> 

T 

(SHOW  T) 

---  [SUCCEED  by  RULE34]  ---> 

(SHOW  (ANO  [ANO  [IN-SUIT-LED  CAROl]  T]  [HIGHER  CAROl  (CARO-OF  ME)])) 

(ANO  [IN-SUIT-LEO  CAROl]  T) 

---  [SIMPLIFY  by  RULE343]  ---> 

(IN-SUIT-LEO  CARD!) 


|  6:51 


CARD! 

[EVAl  by  RULE127]  --> 

DK 


§D.6.  DERIV6:  Avoid  Taking  Points  (Play  a  Low  Card) 


|  6:52 

|  8:63 


|>  6:64 


||  6:66 


||  6:66 


II  6:57 


|<  6:58 


|  6:59 


|  6:60 


(IN-SUIT-LED  OK) 

---  (ELABORATE  by  RULE124]  — -> 

('  (SUIT  OF  OK)  (SUIT-LED)) 

(SUIT-LED) 

---  (ELABORATE  by  RULE124]  — > 

(SUIT-OF  (CARD-OF  (LEAOER) ) ) 

(•  (SUIT-OF  OK)  (SUIT-OF  (CARO-OF  (LEADER)))) 
— -  (by  RULE91]  ---> 

(SHOW  (AMO  [>  OK  (CARD-OF  (LEADER))])) 

(CARD-OF  (LEADER)) 

---  [EVAL  by  RULE346]  ---> 

OK 

(»  OK  OK) 

---  (EVAL  by  RULE179]  — > 

T 

(AMO  T) 

— -  (COMPUTE  by  RULE236]  — > 

T 

(SHOW  T) 

---  (SUCCEED  by  RULE53]  — > 

(SHOW  (AND  T  (HIGHER  CAR01  (CARD-OF  ME)])) 

(AND  T  [HIGHER  CAROI  (CARO-OF  ME)]) 

—  -  [SIMPLIFY  by  RULE341 ]  ---> 

(HIGHER  CAROI  (CARO-OF  HE)) 

CAROI 

---  [EVAL  by  RULE  127]  ---> 

OK 


(SHOW  (HIGHER  OK  (CARO-OF  ME))) 

<  5:61  ---  [GIVE-UP  by  RULE  161]  — > 

(ACHIEVE  (•>  (AND  [IN-SUIT-LED  (CARO-OF  ME)]  [TRICK-HAS-POIMTS]) 
(HIGHER  OK  (CARD-OF  ME)))) 

(HIGHER  OK  (CARO-OF  ME)) 

6:82  — -  [by  RULE  153]  ---> 

(LOWER  (CARD-UF  ME)  OK) 

[Final  expression:] 

(ACHIEVE  (»>  (AND  [IN-SUIT-LED  (CARO-OF  ME)]  [TRICK-HAS-POIMTS]) 
(LOWER  (CARO-OF  ME)  OK))) 

(ASSUMING  (CARD-OF  (LEAOER))  ->  OK) 

NIL 

<73>recordf1  le 


RECORO  FILE  OSK:  (OV6O07  PZG)  CLOSED  07-OEC-80  18:32:12 


D.7.  DERIV7:  Get  the  Lead 


RECORO  FILE  DSK:  (0V7007  .  PZG)  OPENED  07-0EC-80  14:28:11 
NIL 

<100>p-11nks  nil 

(DERIV7  STARTED  07-DEC -80  14:  7:50-  --OOMAIN:  HEARTS  -PROBLEM: 
(ACHIEVE  (LEADING  ME))) 


[Initial  expression:] 

(ACHIEVE  (LEADING  ME)) 

(LEAOING  ME) 

7:1  ---  [ELABORATE  by  RULE124]  ---> 

(•  (LEAOER)  ME) 

(LEADER) 

7:2  ---  [ELABORATE  by  RULE124]  — > 
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(PREVIOUS  (TRICK-WINNER) ) 

(ACHIEVE  («  (PREVIOUS  (TRICK-WINNER))  ME)) 

?:3  — -  (by  RULE366]  — -> 

(ACHIEVE  (»  (TRICK-WINNER)  ME)) 

(-  (TRICK-WINNER)  ME) 

7:4  ---  (REDUCE  by  RULE301]  — > 

(ANO  [IN-SUIT-LEO  (CARO-Of  M€)] 

[FQRALL  XI  (CAROS- IN-SUIT-LEO  (CAROS-PLAYEO) ) 
(NOT  (HIGHER  Xl  (CARO-OF  ME)))]) 

(HIGHER  XI  (CARO-OF  ME)) 

7:8  ---  (by  RULE  153)  ---> 

(LOWER  (CARO-OF  ME)  Xl) 

7:6  —  (REDUCE  by  RULE154]  ---> 

(LOW  (CARO-OF  ME)) 

(FORALL  Xl  (CAROS- IN-SUIT-LEO  (CAROS-PLAYEO)) 
(NOT  (LOW  (CARO-Of  ME)))) 

7:7  ---  (REMOVE-QUANT  by  RULE  166 )  — -> 

(NOT  (LOW  (CAROOf  ME))) 

7:8  ---  (by  RULE387]  ---> 

(HIGH  (CARO-OF  ME)) 

(Final  expression-.] 

(ACHIEVE  (ANO  (IN-SUIT-LED  (CAROOF  ME))  [HIGH  (CARO-OF  ME)])) 
<l>r«cordf lie 

RECORD  FILE  DSK:  (DV7D07  .  PZG)  CLOSED  07-DEC-80  14:26:41 


D.8.  DERIV8:  Get  Void 


RECORO  FILE  DSK:  (DV8007  .  PZG)  OPENEO  070EC-80  14:33:26 
NIL 

<41>p-T Inks  nil 

(OERIV8  STARTED  *07-OEC-80  14:27:34"  --OOMAIN:  HEARTS  --PROBLEM: 
(ACHIEVE  (VOID  ME  SO))) 


(Initial  expression:] 

(ACHIEVE  (VOID  ME  SO)) 

(VOID  ME  SO) 

6:1  ---  (ELABORATE  by  RULE  134]  ---> 

(NOT  (EXISTS  Cl  (CAROS- IN-HAND  HE)  (IN-SUIT  Cl  SO))) 

6:7  --  [by  RULE  160]  ---> 

(EMPTY  (SIT-Of  Cl  ( CAROS- IN-HAND  ME)  (IN-SUIT  Cl  SO))) 

(ACHIEVE  (EMPTY  (SET-OF  Cl  (CARDS-IN-HANO  ME)  (IN-SUIT  Cl  SO)))) 

8:3  ---  [REDUCE  by  RULE6]  ---> 

(UNTIL  (VOID  ME  SO) 

(ACHIEVE  ( REMOVE -1 -FROM  (SET-OF  Cl  (CAROS- IN-HANO  ME)  (IN-SUIT  Cl  SO))))) 

(REMOVE! -FROM  (SET-OF  Cl  (CAROS- IN-HANO  ME)  (IN-SUIT  Ct  SO))) 

8:4  ---  [REDUCE  by  RULE7 ]  — > 

(UNDO  (ANO  [IN  Cl  (CAROS- IN-HANO  ME)]  (IN-SUIT  Cl  SO])) 

8:6  ---  [REDUCE  by  RULE36]  ---> 

(AND  (UNOO  (IN  Cl  (CARDS- IN -HAND  ME))]  (IN-SUIT  Cl  SO]) 

(CARDS-IN-HANO  ME) 

8:6  ---  [ELABORATE  by  RULE124]  ---> 

(SET-OF  C2  (CARDS)  (HAS  ME  C2)) 

(IN  Cl  (SET-OF  C2  (CAROS)  (HAS  ME  C2))) 

8:7  ---  (REMOVE -QUANT  by  RULE10]  — > 

(ANO  [IN  Cl  (CAROS)]  [HAS  ME  Cl]) 

(UNOO  (ANO  (IN  Cl  (CAROS)]  [HAS  ME  Cl])) 

6:8  ---  [REDUCE  by  RULE36]  — > 


t 
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(AND  [UNOO  (HAS  ME  Cl)]  [IN  Cl  (CANOS)]) 


(HAS  ME  Cl) 


8:9 

---  [ELABORATE  by  RULE  124] 
(AT  Cl  (HANO  ME)) 

8:10 

(UNOO  (AT  Cl  (HANO  ME))) 

—  -  [RECOGNIZE  by  RULE388]  — > 
(MOVE  Cl  (HANO  ME)  LOCI) 

8:11 

---  [RECOGNIZE  by  RULE123]  — > 
(PLAY  ME  Cl) 

8:12 

(IN  Cl  (CARDS)) 

—  -  [EVAL  by  RULE346]  — > 

T 

8:13 

(ANO  (PLAY  ME  Cl]  T) 

---  [SIMPLIFY  by  RULE343]  ---> 

(PLAY  ME  Cl) 

3:  14 

(AND  [PLAY  ME  Cl]  (IN-SUIT  Cl  SO]) 

---  [RECOGNIZE  by  RULEI23]  ~-> 

(PLAY-SUIT  ME  SO) 


[F1n«l  expression:] 

(UNTIL  (VOIO  ME  SO)  (ACHIEVE  (PUY-SUIT  ME  SO))) 
(ASSUMING  (IN  C!  (CAPOS))) 


<42>recordf lie 

RECORD  FILE  DSK:  (OV8D07  .  PIG)  CLOSED  07-DEC-80  14:33:59 


D.9.  DERIV9:  Decide  if  an  Opponent  is  Void  (Based  on  Distribution) 


RECORD  FILE  DSK:  (DV9D07  .  PIG)  OPENED  07 -DEC-80  18:32:46 
MIL 

<2t>p-Hnks  nil 

(QERIV9  STARTEO  "24-APR-80  01:42.24"  --DOMAIN:  HEARTS  --PROBLEM: 
(EVAL  (VOID  PO  SO))) 


[Tnttlet  expression:] 

(EVAL  (VOIO  PO  SO)) 

(VOIO  PO  SO) 

9:1  [ELABORATE  by  RULE  124]  — -> 

(NOT  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO))) 

(EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO)) 

>  9:2  ---  [by  RULE  189]  ---> 

(SHOM  (•  (EXISTS  Cl  (CARDS- IN-HANO  PO)  (IN-SUIT  Cl  SO)) 

(HI  (DISJOINT  (CAROS- IN-HANO  PO)  SI)))) 

(DISJOINT  (CARDS- IN-HANO  PO)  SI) 

|  9:3  ---  [ELABORATE  by  RULE124]  ---> 

(NOT  (OVERLAP  (CAROS- IN-HANO  PO)  SI)) 

(OVERLAP  (CAROS- IN-HANO  PO)  SI) 

|  9:4  —  [ELABORATE  by  RULE124]  — -> 

(EXISTS  XI  (CAROS- IN-HANO  PO)  (IN  XI  SI)) 


/>  9:5 


II  • 


(•  (EXISTS  Cl  (CAROS- IN-HANO  PO)  (IN-SUIT  Cl  SO)) 

(Ml  (NOT  (EXISTS  XI  (CAROS- IN-HANO  PO)  (IN  XI  SI))))) 
---  [REDUCE  by  RULE212]  ---> 

(SHOM  (•  (EXISTS  Cl  (CAROS- IN-HANO  PO)  (IN-SUIT  Cl  SO)) 

(EXISTS  XI  (CAROS- IN-HANO  PO)  (IN  XI  SI)))) 

(•  (EXISTS  CJ  (CARDS- IN -HAND  PO)  ( IN-SUIT  Cl  SO)) 

(EXISTS  XI  (CAROS- IN-HANO' PQ)  (IN  XI  SI))) 

---  [REDUCE  by  RUL1192)  — > 

(•  (IN-SUIT  Cl  SO)  (IN  Cl  SI)) 
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II  *:I 

— -  [by  RULE  193]  — -> 

(-  SI  (SET-OF  Cl  (DOMAIN  Cl  (IN-SUIT  Cl  SO))  (IN-SUIT  Cl  SO))) 

II  9:S 

(IN-SUIT  Cl  SO) 

—  [ELABORATE  by  RULE124]  - > 

(■  (SUIT-OF  Cl)  SO) 

II  9:» 

(DOMAIN  Cl  (-  (SUIT-OF  Cl)  SO)) 

---  [by  RULE196]  — > 

(DOMAIN  Cl  (SUIT-OF  Cl)) 

||  9: 10 

---  [by  RULE  196]  — -> 

(DOMAIN  SUIT-OF) 

II  »:ll 

---  [FACT  by  RULE197]  ---> 

(CAROS) 

II  9.12 

(SET-OF  Cl  (CAROS)  (IN-SUIT  Cl  SO)) 

—  -  [RECOGNIZE  by  RULE  123]  — -> 

(CARDS- IM-SU1T  SO) 

II  9:13 

<•  SI  (CARDS- IN-SUIT  SO)) 

—  [REDUCE  by  RULE194]  ---> 

j 

(St  <-  BINDING 

:  (CARDS- IN-SUIT  SO)) 

|<  9:14 

(SHOW  T) 

— -  [SUCCEED  by  RULE34]  — -> 

(SHOW  (•  HI  (INVERSE  (LAMBDA  (EXISTSl)  (NOT  EXISTS1))))) 

(LAMBDA  (EXISTSl)  (NOT  EXISTSl)) 

|  9:15  — -  [SIMPLIFY  by  RULE216]  ---> 

NOT 

(•  HI  (INVERSE  NOT)) 

|  9:16  —  [REDUCE  by  RULE  104]  — > 

T 


(SHOW  T) 

<  9:17  ---  [SUCCEED  by  RULE  190]  ---> 

(EVAL  (NOT  (HI  (DISJOINT  (CARDS- IN-HAND  PO)  SI)))) 

HI 

9:1$  — -  [EVAl  by  RULE127]  — > 

(INVERSE  NOT) 

(NOT  ((INVERSE  NOT)  (DISJOINT  (CAROS- IN -HAND  PO)  SI))) 
9:19  ---  [SIMPLIFY  by  RULE218]  — -> 

(DISJOINT  (CARDS- IN-HANO  PO)  SI) 

SI 

9:20  ---  [EVAL  by  RULE  12 7]  — -> 

(CARDS- IN-SUIT  SO) 


9:21 


>  9:22 


|  9:23 

|  9:24 


(DISJOINT  (CARDS- IN-HAND  PO)  (CARDS- IN-SUIT  SO)) 

---  [by  RULE  19$)  ---> 

(PR-DISJOINT  (CARDS- IN-HAND  PO) 

(CAROS- IN-SUIT  SO) 

(COMMON -SUPERSET  (CAROS- IN-HAND  PO)  ( CARDS- IN-SUIT  SO))) 

(COMMON-SUPERSET  (CARDS- IN-HAND  PO)  (CARDS- IN-SUIT  SO)) 
---  [by  RULE 2 68]  — > 

(CONSIOCR  (COMMON -SUPERSET  (CAROS- IN-HAND  PO)  (CARDS- IN-SUIT  SO))) 

(CAROS- IN-HANO  PO) 

---  [ELABORATE  by  RULE124]  ---> 

(SET-OF  C2  (CAROS)  (HAS  PO  C2)) 

(CAROS- IN- SUIT  SO) 

---  [ELABORATE  by  RULE124]  — -> 

(SET-OF  C3  (CAROS)  (IN-SUIT  C3  SO)) 


(COMMON- SUPERSET  (SET-OF  C2  (CAROS)  (HAS  PO  C2)) 
(SET-OF  C3  (CAROS)  (IN-SUIT  C3  SO))) 

(.  9:26  ---  (REDUCE  by  RULE  199]  — > 

(CAROS) 


(CONSIDER  (CARDS)) 

<  9:26  ---  [by  RULE269]  — > 

(EVAL  (PR-OISJOINT  (CAROS- IN-HANO  PO)  (CARDS- IN- SUIT  SO)  (CAROS))) 
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>  9:27 

1  9:28 

|  9:29 

|  9:30 

|  9:31 

|  9:32 

|  9:33 

|  9:34 

|  9:36 

|  9  36 

<  9:37 

9:38 

9:39 

9  40 

9:41 

9:42 

9:43 

9:44 


(PR-DISJOINT  (CARDS- 18- HANO  PO )  (CAROS- IN- SUIT  SO)  (CAROS)) 
---  [by  RULE2Q0]  --> 

(SHOW  («  (CARDS- IN-HA NO  PO)  (FILTER  (CAROS  IN-HANO  PO )  OUT))) 

(»  (CARDS- IN-HANO  PO)  (FILTER  (CAROS- IN-HANO  PO)  OUT)) 

---  [by  RULE218]  — > 

(->  (IN  X2  (CAROS- IN-HANO  PO))  (OUT  X2)) 

(CAROS- IN-HANO  PO) 

—  [ELABORATE  by  RULE  124 ]  ---> 

(SET-OF  C4  (CAROS)  (HAS  PO  C4)) 

(IN  X2  (SET-OF  C4  (CAROS)  (HAS  PO  C4))) 

-  -  [REMOVE -QUANT  by  RULE369 ]  — > 

(HAS  PO  X2 ) 

(OUT  X2) 

---  (ELABORATE  by  RULE124]  — > 

(EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  X2 ) ) 

(•>  (HAS  PO  X2 )  (EXISTS  Pi  (OPPONENTS  ME)  (HAS  PI  X2))) 

[by  RULE329]  ---> 

(EXISTS  PI  (OPPONENTS  ME)  (•>  (HAS  PO  X2 )  (HAS  PI  X2))) 

(*>  (NAS  PO  X2)  (HAS  PI  X2 ) ) 

—  [DISTRIBUTE  by  RULE43]  — > 

(ANO  [■  PO  Pt]  [«  X2  X2 ] ) 

(-  12  X2 ) 

---  [EVAL  by  RULE  179]  —  > 


(ANO  [-  PO  PI)  T) 

---  [SIMPLIFY  by  RULE343]  — > 

(»  PO  PI) 

(EXISTS  PI  (OPPONENTS  ME)  (■  PO  PI)) 

---  [REMOVE -QUANT  by  RULE  162]  — -> 

(IN  PO  (OPPONENTS  ME)) 

(SHOW  (IN  PO  (OPPONENTS  ME))) 

---  (ASSUME  by  RULE32]  ---> 

(EVAL  (PR-OISJOINT  (CAROS- IN-HANO  PO) 

(FILTER  (CAROS- IN- SUIT  SO)  OUT) 
(FILTER  (CAROS)  OUT))) 

(FILTER  (CARDS- IN-SUIT  SO)  OUT) 
---  [RECOGNIZE  by  RULE  123]  — > 
(CAROS -OUT -IN- SUIT  SO) 

(FILTER  (CAROS)  OUT) 

---  [aUOGNIZt  by  RULE  123]  — -> 
(CARDS-OUT) 

(PR-DISJOINT  (CAROS- IN-HANO  PO) 

(CAROS -OUT -  IN- SUIT  SO) 
(CARDS-OUT)) 

---  [ELABORATE  by  RUIE124]  — -> 

(PR  DISJOINT -FORMULA  (#  (CAROS- IN-HANO  PO)) 
(#  (CAROS -OUT- IN- SUIT  SO)) 

(#  (CARDS-OUT))) 


(i  (CAROS- IN-HANO  PO)) 

---  [RECOGNIZE  by  RULE  123]  — -> 
(PCAROS- IN-HANO  PO) 

(«  (CAROS-OUT-IN-SUIT  SO)) 

---  (RECOGNIZE  by  RULE123]  ---> 
(RCAROS-OUT- IN -SUIT  SO) 

(»  (CAROS-OUT)) 

--'  (RECOGNIZE  by  RULE123]  — -> 
(PCAROS-OUT) 

(EVAL  (PR-OISJOINT -FORMULA  ( RCA ROS- IN-HANO  PO) 

(f CARDS-OUT -IN -SUIT  SO) 

(f CAROS-OUT))) 

---  (by  RULE202]  ---) 

(FURCTION-OF  SO 

(DEPENDENCE  (PR-OISJOINT-FORMULA  ( fCAROS* IN-HANO  PO) 


I 
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1 


(KAnos-our-iK-surr  so) 

(KABOS -OUT)) 

SO)) 

(OCPEMOCMCE  (f>«-OISJOnir-fOMIUU  ( KABOS- IN-HAMO  PO) 
(ACAR0S-0UT-IM-$UIT  SO) 

(ACAROS-OUT)) 

SO) 

9:45  — -  [by  MJLE2031  ---> 

( 0 ♦  (0*  (DEPENDENCE  ( fCAROS -OUT* IN- SUIT  SO)  SO) 

(DEPENDENCE  (PR- DISJOINT -FORMULA  AH  AS  AU)  AS))) 

9:46  ---  [SIMPLIFY  by  RULEI7S)  -•-> 

(0*  (DEPENDENCE  { ACAROS-OUT- IN- SUIT  SO)  SO) 

(DEPENDENCE  (Pk-OISJOINT-FORWU  AH  AS  00)  0$)) 

(FUNCTION  OF  SO 

(0*  (DEPENDENCE  (aCAROS-OUT- IN-SUIT  SO)  SO) 

(DEPENDENCE  (PR-OISJOINWORMULA  AH  AS  00)  »%))) 

9:47  — -  [by  RULE2IQ]  ---> 

( FUNCTION -OF  ( ACAROS-OUT- IN-SUIT  SO) 

(0*  INCREASING  (DEPENDENCE  (PR-OISJOINT-fORMULA  AM  AS  AU)  AS))) 

(0*  INCREASING  (DEPENDENCE  (PR-DISJOINT-FORMULA  AM  AS  AU)  AS)) 
9:46  ---  [SIMPLIFY  by  RUIE341]  ---> 

(DEPENDENCE  (PR-QISJOINT-FORMULA  AH  AS  AU)  AS) 

( PR- OISJOINT- FORMULA  AH  AS  AU) 

9:49  [ELABORATE  by  RULE124]  — -> 

(//  (ACHOOSE  (-  AU  AS)  AH)  (ACHOOSE  AU  AH)) 

(DEPENDENCE  (//  (ACHOOSE  (-  AU  AS)  AH)  (ACHOOSE  AU  AH))  AS) 

9:50  —  [by  RULEri06]  ---> 

(0*  (DEPENDENCE  (ACHOOSE  (-  AU  AS)  AH)  AS) 

(D-  (DEPENDENCE  (ACHOOSE  AU  AH)  AS))) 

(OEPENOENCE  (ACHOOSE  AU  AM)  AS) 

9:51  ---  [EVAL  by  RULE204]  ---> 

NIL 

(D-  NIL) 

9.52  ---  [COMPUTE  by  RULE236J  — > 

NIL 

(0*  (OEPENOENCE  (ACHOOSE  (-  AU  AS)  AH)  AS)  NIL) 

9:53  [SIMPLIFY  by  RULE343]  ---> 

(OEPENOENCE  (ACHOOSE  (-  AU  AS)  AH)  AS) 

9:54  —  [REDUCE  by  RULE207]  ---> 

(DEPENDENCE  (-  AU  AS)  AS) 

9:66  [by  RULE 205]  ---> 

(0>  (OEPENOENCE  AU  AS)  (0-  (OEPENOENCE  AS  AS))) 

(OEPENOENCE  AU  AS) 

9:66  —  -  (EVAL  6y  WLE204] - > 

NIL 

(DEPENDENCE  AS  AS) 

9:67  ---  [EVAL  by  RULE 200]  ---> 

INCREASING 

(0-  INCREASING) 

9:58  ---  (COMPUTE  6y  RULE2J6]  ---> 

DECREASING 

(0*  NIL  DECREASING) 

9:59  ---  [COMPUTE  by  RULE236]  ---> 

DECREASING 

(MiUl  Axprttilon:] 

(FUNCTION-OF  (ACAROS-OUT-IN-SUIT  SO)  DECREASING) 

NIL 

<22>r«cordf 11« 

RECORD  FILE  DSN:  (0V9007  .  PIG)  CLOSED  07-0EC-60  18:34:46 
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RECORD  FILE  DSK:  (010007  PZG)  OPENED  Q7-0EC-80  18:36:24 
NIL 

<47>p-11nks  nil 

(0ERIV10  STARTED  "24-APR-0O  20:04:56"  --DOMAIN:  HEARTS  -- PROBLEM: 
(EVAL  (#C ARDS -OUT -IN- SUIT  SO))) 


[Initial  oxprttslon:] 

(EVAL  l#CAROS-OUT- IN-SUIT  SO)) 


(#CARDS-OUT- IN-SUIT  SO) 

101  — -  [ELABORATE  by  RULE  124]  — -> 

(#  (CAROS-OUT-IN-SUIT  SO)) 

(CAROS-OUT- IN-SUIT  SO) 

10:2  ---  (ELABORATE  by  RULE  124]  — -> 

(FILTER  (CARDS- IN-SUIT  SO)  OUT) 

10:3  —  -  [ELABORATE  by  RULE  124]  ---> 

(SCT-OF  XI  (CAROS-IN-SUIT  SO)  (OUT  XI)) 

(0  (SET-OF  XI  (CAROS-IN-SUIT  SO)  (OUT  XI))) 

>  10:4  ---  (TRY- THIS  by  RULE370 ]  — > 

(SHOW  (NOT  (DURING  ( ROUND- IN -PROGRESS )  (CAUSE  (OUT  XI))))) 


|  10:5 

|  10:8 

|  10:7 

|  10:8 

|  10:9 


(OUT  XI) 

—  -  [ELABORATE  by  RULE  124]  — -> 

(EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  XI)) 

(CAUSE  (EXISTS  PI  (OPPONENTS  ME)  (HAS  PI  XI))) 
---  [by  RULE329]  — -> 

(EXISTS  PI  (OPPONENTS  ME)  (CAUSE  (HAS  PI  XI))) 


(HAS  PI  XI) 

[ELABORATE  by  RULE  124]  — -> 
(AT  XI  (HAND  PI)) 

(CAUSE  (AT  XI  (HAND  PI))) 

[RECOGNIZE  by  RULE358]  — -> 

(MOVE  XI  LOCI  (HAND  PI)) 

---  [RECOGNIZE  by  RULE123]  — -> 
(GET-CARD  PI  XI  LOCI) 


(OURING  (ROUND- IN-PROGRESS) 

(EXISTS  PI  (OPPONENTS  ME)  (GET  CARO  Pt  XI  LOCI))) 
|  10:10  ---  [COMPUTE  by  RULE57]  ---> 

NIL 


(NOT  NIL) 

|  10:11  — -  [COMPUTE  by  RULE 230]  — -> 

T 


(SHOW  T) 

<  10:12  ---  [SUCCEEO  by  RULE34]  — -> 

(EVAL  (-  (0  (SET-OF  XI  (CARDS- IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUNO- IN-PROGRESS)  (OUT  XI)))) 

(f  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(WAS-OURING  (CURRENT  ROUND- IN- PROGRESS)  (UNOO  (OUT  XI))))))) 


>  10:13 


|  10:14 


(BEFORE  (CURRENT  ROUNO- IN-PROGRESS)  (OUT  XI)) 
— •  [by  RULE268]  ---> 

(CONSIDER  (BEFORE  (CURRENT  ROUNO- IN- PROGRESS)  (OUT  XI))) 


(OUT  XI) 

---  [REDUCE  by  RULE301]  — > 

(NOT  (OR  [IN-POT  XI]  [AT  XI  HOLE]  [HAS  ME  XI])) 

(BEFORE  (CURRENT  ROUNO- IN- PROGRESS) 

(NOT  (OR  [IN-POT  XI]  [AT  XI  HOLE]  (HAS  ME  XI]))) 
---  [DISTRIBUTE  by  RULE371 ]  ---> 

(NOT  (BEFORE  (CURRENT  ROUND- IN-PROGRESS) 

(OR  [IN-POT  XI]  [AT  XI  HOLE]  [MAS  ME  XI]))) 


|  10: IB 
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|  10:14 

|  10:1? 

|  10: 16 

|  10:19 

|  10:20 

|  10:21 

<  10:22 

10:23 

10:24 

>  10:20 

|  10:20 

|  10:2? 

|  10:28 

|  10:29 
|  10:30 

<  10:31 


(BEFORE  (CURRENT  ROUND- I N- PROGRESS) 

(OR  [IN-POT  XI]  [AT  XI  HOLE]  [HAS  ME  XI])) 

—  [DISTRIBUTE  by  RULE371]  — > 

(Oft  [BEFORE  (CURRENT  ROUND- IN-PROGRESS)  (IN-POT  XI)) 
[BEFORE  (CURRENT  ROUND- IN- PROGRESS)  (AT  XI  HOLE)] 
[BEFORE  (CURRENT  R0UN0-IN-PR06RESS)  (HAS  ME  XI)]) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (IN-POT  XI)) 

—  [FACT  by  RULE372)  — > 

NIL 

(OR  NIL  [BEFORE  (CURRENT  ROUND- IN-PROGRESS)  (AT  XI  HOLE)] 
[BEFORE  (CURRENT  ROUND- IN-PROGRESS)  (HAS  ME  XI)]) 

---  [SIMPLIFY  by  RUIE1 78)  — > 

(OR  [BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (AT  XI  HOLE)] 
[BEFORE  (CURRENT  ROUNO- IN- PROGRESS)  (HAS  ME  Xl)]) 

(AT  XI  HOLE) 

---  [ASSUME  by  RULE373)  — -> 

NIL 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  NIL) 

— -  [EVAL  by  RULE374]  - > 

NIL 

(OR  NIL  [BEFORE  (CURRENT  ROUNO-IN-PROGAESS)  (HAS  ME  XI)]) 
---  [SIMPLIFY  by  RULE341]  — -> 

(BEFORE  (CURRENT  ROU^D- IN-PROGRESS )  (HAS  ME  XI)) 

(CONSIDER  (NOT  (BEFORE  (CURRENT  ROUND- IN- PROGRESS)  (HAS  ME  Xl)))) 

— -  [by  RULE 269]  — -> 

(EVAL  (-  (#  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(NOT  (BEFORE  (CURRENT  ROUNO- IN-PROCRESS)  (HAS  ME  XI))))) 

(*  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUND-IN-PROGRESS)  (UNDO  (OUT  XI))))))) 

(*  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(NOT  (BEFORE  (CURRENT  ROUND- IN-PROGRESS)  (HAS  ME  Xl))))) 

---  [by  RULE375]  — -> 

(~  (A  (CARDS- IM-SUIT  SO)) 

(0  (SET-OF  Xl  (CARDS- IN- SUIT  SO) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  Xl))))) 

(f  (CARDS- IN-SUIT  SO)) 

—  [FACT  by  RULE376]  — > 

13 


(UNOO  (OUT  Xl)) 

— -  [by  RULE 2 68]  — > 

(CONSIDER  (UNOO  (OUT  Xl))) 

(OUT  Xl) 

---  [ELABORATE  by  RULE124]  — -> 

(EXISTS  P3  (OPPONENTS  ME)  (HAS  P3  Xl)) 

(UNOO  (EXISTS  P3  (OPPONENTS  ME)  (HAS  P3  Xl))) 
---  [by  RULE329]  ---> 

(EXISTS  P3  (OPPONENTS  ME)  (UNOO  (HAS  P3  Xl))) 
(HAS  P3  Xl) 

---  [ELABORATE  by  RULE124]  — -> 
(AT  Xl  (HAND  P3 ) ) 

(UNDO  (AT  Xl  (HANO  P3) ) ) 

—  [RECOGNIZE  by  RULE368]  — -> 

(MOVE  Xl  (HANO  P3)  L0C2) 

—  [RECOGNIZE  by  RULE  123]  — > 

(PLAY  P3  Xl; 

(CONSIDER  (EXISTS  P3  (OPPONENTS  ME)  (PLAY  P3  Xl))) 

---  [by  RULE 269]  ---> 

(EVAL  (-  (-  13 

(f  (SET-OF  Xl  (CARDS- IN -SUIT  SO) 

(BEFORE  (CURRENT  ROUND- tN- PROGRESS)  (HAS  ME  Xl))))) 

(f  (SET-OF  Xl  (CARDS- IN- SUIT  SO) 

(WAS-OURING  (CERENT  ROUNO- IN- PROGRESS) 

(EXISTS  P3  (OPPONENTS  ME)  (PLAY  P3  Xl))))))) 


[Ffff«1  «xpr«if : ] 
(EVAL  (-  (-  13 
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(#  (SET-OF  XI  (CARDS- IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  HE  XI))))) 

(#  (SET-OF  XI  (CAROS- IN-SUIT  SO) 

(UAS-OURING  (CURRENT  ROUNO- IN-PROGRESS) 

(EXISTS  P3  (OPPONENTS  HE)  (PLAY  P3  XI))))))) 
NIL 

<46>recordf lie 

RECORD  FILE  DSK:  (010007  .  PZG)  CLOSED  07-DEC-80  18:37:05 


D.ll.  DERIV11:  Decide  if  an  Opponent  is  Void  (Based  on  Behavior) 


RECORD  FILE  OSK:  (D11D07  .  PZG)  OPENED  07-OEC-80  18:37:28 
NIL 

<82>p-MnEs  nil 

(DERJV11  STARTED  "24-APR-80  22:47:57"  --DOMAIN:  HEARTS  -PROBLEM: 
(EVAL  (VOIO  PO  SO))) 


[Initial  expression.) 

(EVAL  (VOID  PO  SO)) 

>  11:1  ---  [by  RULE2Z7]  — > 

(SHOW  (LEGAL  PI  Cl)) 

(LEGAL  PI  Cl) 

|>  11.2  ---  [FACT  by  WLE228J  — > 

(SHOW  (=•  Cl  (CARO-OF  Pi))) 

(»  Cl  (CARO-OF  PI)) 

)|  11.3  — -  [REDUCE  by  RULE  194]  — > 

T 

(Cl  <-  B I  NO l NG  :  (CARD-OF  PI)) 

(SHOW  T) 

)<  11:4 

---  [SUCCEED  by  RULE 53]  — -> 

(SHOW  T) 

<  11:5 

~~  [SUCCEED  by  RULE34J  ---> 

(EVAL  (»>  (LEGAL  Pi  Cl)  (VOID  PO  SO))) 

Cl 

11:6  ---  [EVAL  by  RULE127]  ---> 

(CARO-OF  PI) 

(LEGAL  Pi  (CARO-OF  Pi)) 

11:7  ---  [ELABORATE  by  RULE124]  ---> 

(ANO  [HAS  Pi  (CARO-OF  Pi)] 

[«>  (LEADING  PI) 

(OR  [CAN -LEAO- HEARTS  PI]  [NEQ  (SUIT-OF  (CARD-OF  PI))  H])] 

[■>  (FOLLOWING  PI) 

(OR  [VOID  PI  (SUIT-LED)]  [IN-SUIT  (CARO-OF  PI)  (SUIT-LED) ]) ]) 

(•>  (AND  [HAS  PI  (CARO-OF  PI)] 

[O  (LEAOIKG  PI) 

(OR  [CAN- LEAD-HEARTS  PI]  [NEO  (SUIT-OF  (CARO-OF  PI))  H]) ] 

[O  (FOLLOWING  PI) 

(OR  [VOID  Pi  (SUIT-LED)]  [IN-SUIT  (CARD-OF  PI)  (SUIT-LED)])]) 
(VOIO  PO  SO)) 

11:8  ---  [REDUCE  by  RULE224]  — -> 

(»>  (»>  (FOLLOWING  PI) 

(OR  (VOID  PI  (SUIT-LED)]  [IN-SUIT  (CARO-OF  PI)  (SUIT-LED)])) 

(VOID  PO  SO)) 

11.9  ---  (REDUCE  by  RULE 728]  — > 

(AND  [FOLLOWING  PI] 

[*>  (OR  [VOIO  PI  (SUIT-LED)]  [IN-SUIT  (CARD-OF  Pi)  (SUIT-LED))) 

(VOID  PO  SO)]) 

{•>  (OR  [VOIO  PI  (SUIT-LED)]  [Il-SUIT  (CARD-OF  Pt)  (SUIT-LED)]) 

(VOIO  PO  SO)) 
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11:10 


11:11 


— -  [REDUCE  by  RULE225]  — > 

(AND  [NOT  (OR  [IN-SUIT  (CARD-QF  PI)  (SUIT-LED)])] 
[*>  (VOID  PI  (SUIT-LED))  (VOIO  PO  SO)]) 

(*>  (voro  pi  (Suit-lco))  (void  po  so)) 

---  [DISTRIBUTE  by  RULE 43]  — > 

(AND  (■  PI  PO]  [»  (SUIT-LED)  SO]) 


{•  PI  PO) 

11:12  — -  [REDUCE  by  RULE  194]  --> 

T 

(PI  <-  BINDING  :  PO) 


(ANO  T  [«  (SUIT-LED)  SO]) 

11:13  — -  [SIMPLIFY  by  RULE341]  — > 

(»  (SUIT-LED)  SO) 

(OR  [IN-SUIT  (CARD-OF  PI)  (SUIT-LED)]) 

11:14  — -  [SIMPLIFY  by  RULE  178]  — > 

(IN-SUIT  (CARO-OF  PI)  (SUIT-LED)) 

PI 

11:15  [EVAL  by  RULE127]  — -> 

PO 

PI 

11:16  ---  [EVAL  by  RULE127]  ---> 

PO 

(AND  [FOLLOWING  PO] 

tANO  [NOT  (IN-SUIT  (CARO-OF  PO)  (SUIT-LED))]  [*  (SUIT-LED)  SO]]) 
11:17  —  [SIMPLIFY  by  RULE177]  ---> 

(AND  [NOT  (IN-SUIT  { CARD’Of  PO)  (SUIT-LED))] 

[«  (SUIT-LED)  SO] 

[FOLLOWING  PO]) 

(NOT  (IN-SUIT  (CARD-OF  PO)  (SUIT-LED))) 

11:16  ---  [RECOGNIZE  by  RULE123]  — -> 

(BREAKING  SUIT  PO) 

[Final  expression : ] 

(EVAL  (AND  C8REAKr«GSUlT  PO]  ('  (SUIT-L£D)  SO]  [FOLLOWING  PO])) 

NIL 

<33>recordf 1 )• 

RECORD  FILE  D$K:  (D11D07  .  PZG)  CLOSED  O7-OEC-0O  16:38:34 


D.12.  DERIVI2:  Decide  if  an  Opponent  is  Void  (Based  on  Past) 


RECORO  FILE  DSN:  (D12D07  .  PZG)  OPENED  O7-OCC-60  16:04:36 
NIL 

<37>p-HnkS  nil 

(DERIV1Z  STARTED  "07-0EC-80  14:59:15"  fLINKS  13  --OOMAIN:  HEARTS 
-PROBLEM;  (EVAL  (VOID  PO  $0))) 


[Initial  expression:] 

(EVAL  (VOID  PO  SO)) 

VOIO  PO  SO) 

>  12:1  ---  [SUFFICE  by  RULE234]  — > 

(SHOW  (NOT  (DURING  ( ROUND- IN- PROGRESS)  (UNDO  (VOIO  PO  SO))))) 


(VOIO  PO  SO) 

\  12:2  ---  (ELABORATE  by  RULE  124]  --> 

(NOT  (EXISTS  Cl  (CAROS-IN-HANO  PO)  (IN-SUIT  Cl  SO))) 

(UNDO  (NOT  (EXISTS  Cl  (CAROS- IN-HAND  PO)  (IN-SUIT  Cl  SO)))) 
|12:3  ---  [RECOGNIZE  by  RULE377]  ---> 

(CAUSE  (EXISTS  Cl  (CAROS-IN-HANO  PO)  (IN-SUIT  Cl  SO))) 

(CARDS- IN-HANO  PO) 

|  12:4  ---  [ELABORATE  by  RULE124]  ---> 

(SET-OF  C2  (CAROS)  (HAS  PO  C2)) 
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(EXISTS  Cl  (SET-OF  C2  (CAROS)  (HAS  PO  C2))  (IN-SUIT  Cl  SO)) 
|  12:6  ---  [by  RULE  136]  — -> 

(EXISTS  Cl  (CARDS)  (ANO  [HAS  PO  Cl]  [IM-SUIT  Cl  SO])) 

(CAUSE  (EXISTS  Cl  (CARDS)  (AMD  [HAS  PO  Cl]  [IM-SUIT  Cl  SO]))) 

|  12:6  ---  (by  RULE329]  -~> 

(EXISTS  Cl  (CAROS)  (CAUSE  (AMO  [HAS  PO  Cl]  [IM-SUIT  Cl  SO]))) 

(CAUSE  (AMO  [HAS  PO  Cl]  [IM-SUIT  Cl  SO])) 

|  12:7  ---  [REDUCE  by  RULE35]  — > 

(AMD  [CAUSE  (HAS  PO  Cl)]  [IM-SUIT  Cl  SO]) 

(HAS  PO  Cl) 

)  12:8  ---  [ELABORATE  by  RULE124]  ---> 

(AT  Cl  (HAMO  PO)) 

(CAUSE  (AT  Cl  (HAMO  PO))) 

|  12:9  ---  [RECOGMIZE  by  RULE358]  — > 

(MOVE  Cl  LOCI  (HAND  PO)) 

|  12:10  ---  [RECOGMIZE  by  RULE123]  — > 

(GET -CARD  PO  Cl  LOCI) 

(DURING  (ROUND- IN-PROGRESS) 

(EXISTS  Cl  (CAROS)  (ANO  [GET-CARO  PO  Cl  LOCI]  [IM-SUIT  Cl  SO]))) 

|  12:11  ---  [COMPUTE  by  RULE57]  — > 

MIL 

(MOT  NIL) 

|  12:12  — -  [COMPUTE  by  RULE 236]  — -> 


(SHOW  T) 

<12:13  ---  [SUCCEED  by  WJLE34]  — > 

(EVAL  ( WAS-OURIMG  (CURRENT  ROUND- IN- PROGRESS)  (VOIO  PO  SO))) 

[Final  expression:] 

(EVAL  (WAS-OURIMG  (CURRENT  ROUND-IN-PROGRESS)  (VOID  PO  SO))) 
<38>recoPdf 1 le 

RECORD  FILE  DSK:  (012007  .  PZG)  CLOSED  07-DEC-80  16:06:26 


D.13.  DERIV13:  Heuristic  Search  to  Generate  Cantus 


RECORD  FILE  DSK:  (013D07  .  PZG)  OPENED  07-0EC-80  18:40:00 
NIL 

<8>p-11nKs  nil 

(DERIV13  STARTED  "25-APR-80  18:37:30"  NLIMKS  116  --DOMAIN:  MUSIC 
-PROBLEM:  (ACHIEVE  ( LEGAl-CAMTUS!  (CANTUS)))) 


.Initial  expression:] 

(ACHIEVE  (LEGAL-CAMTUS!  (CANTUS) ) ) 

(LEGAl-CAMTUS!  (CANTUS)) 

13:1  ---  [by  RULE 306]  ---> 

HSM1 

(HSM1  <-  PROBLEM  :  (LEGAL-CAMTUS!  (CANTUS))) 

IMSMI  <-  OBJECT  :  (CANTUS)) 

(HSMl  <-  CHOICE-SEQ  :  (CHOICE-SEQ-OF  (CANTUS))) 

*  13  2  ---  [by  RULE312]  —  > 

(CONSIOER  PROP  (CHOICE-SEQ-OF  (CANTUS))) 

(CANTUS) 

13  J  --  [ELABORATE  by  RULE124]  — -> 

(EACH  II  ( LB : UB  l  (CANTUS~LENGTH) )  (CHOOSE-MOTE  II)) 


(CHOICE-SEQ-OF 

(EACH  II  ( LB : UB  1  (CANTUS* LENGTH) )  (CHOOSE-NOTE  II))) 
-  [DISTRIBUTE  by  RULE307]  — > 

(APPLY  APP1N0 


1  « 
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(EACH  II  (LB:UB  1  (CAMTUS-LENGTH) ) 

(CH01CE-SEQ-0F  (CHOOSE-MOTE  II)))) 

(CHOOSE *MOTE  II) 

|  13:5  —  (ELABORATE  by  RULEX24 J  '“> 

(CHOOSE  (MOTE  II)  (TOMES)  (MOTE  II)) 

(CHOICE-SEO'OF  (CHOOSE  (MOTE  II)  (TOMES)  (MOTE  II))) 
|  13:8  ---  [RECOGNIZE  by  RULE309]  — -> 

(LIST  (CHOOSE  (MOTE  II)  (TOMES)  (MOTE  II))) 

(APPLY  APPEND 

(EACH  II  {LB.UB  I  (CAMTUS-LENGTH)) 

(LIST  (CHOOSE  (MOTE  II)  (TOMES)  (MOTE  IX))))) 

(  13:7  ---  (SIMPLIFY  by  RULE 310]  ---> 

(EACH  IX  ( LB : UB  1  (CAMTUS-LENGTH) ) 

(CHOOSE  (MOTE  II)  (TOMES)  (MOTE  II))) 


(COMSIDER-PROP 

(EACH  IX  (LB : UB  1  (CAMTUS-LENGTH) ) 

(CHOOSE  (MOTE  U)  (TOMES)  (NOTE  IX)))) 

<  13 : 8 

— *  [SUCCEED  by  RULE313]  ---> 

(ACHIEVE  HSML) 

(HSM1  <-  CHOICE-SEO 

(EACH  IX  (LB:U8  X  (CAMTUS- LENGTH) ) 

(CHOOSE  (NOTE  11)  (TOMES)  (NOTE  IX)))) 

HSMX 

13:9  ---  (ELABORATE  by  RULE31I]  — > 

HSMX 

(HSMX  <-  SEQUENCE  :  MOTE) 

(HSM1  <*  CHOICES  :  (PROJECT  MOTE  (LB.UB  1  (CAMTUS-LENGTH)))) 

(HSMX  <-  CHOICE-SETS  :  (LAM80A  (IX)  (TOMES))) 

(HSM1  <-  INDICES  :  ( LB : UB  1  (CAMTUS-LENGTH))) 

(HSMX  <•-  IMOEX  .  II) 

(HSM1  <-  VARIABLES  :  MIL) 

(HSM1  <-  BINDINGS  :  MIL) 

(H$MX  <-  INITIAL-PATH  ;  MIL) 

(HSM1  <-  COMPLETION-TEST 

(LAMBOA  (PATH)  (■  (#  PATH)  (#  (LB:UB  X  (CAMTUS-LENGTH)))))) 

>  13:10  ---  [by  RULE314]  ---> 

(COMSIDER-PROP 

(REFORMULATE  ( LEGAL-CAMTUS!  (CAMTUS)) 

(PROJECT  MOTE  (L8:UB  1  (CAMTUS-LEMGTH ) ) ) ) ) 

(CAMTUS) 

---  [ELABORATE  by  RULE  124]  ---> 

(EACH  12  ( L8 : UB  X  (CAMTUS-LENGTH))  (CHOOSE-MOTE  12)) 

(CHOOSE -MOTE  12) 

---  [ELABORATE  by  RULE  124]  — > 

(CHOOSE  (MOTE  12)  (TONES)  (MOTE  12)) 

---  [REDUCE  by  RULE238]  — > 

(NOTE  12) 

(EACH  12  (LB.UB  1  (CAMTUS-LENGTH))  (MOTE  12)) 

---  [RECOGMIZE  by  RULE123]  — -> 

(PROJECT  MOTE  (LB: UB  X  (CAMTUS-LENGTH))) 

(REFORMULATE  (LEGAL-CAMTUS!  (PROJECT  NOTE  (LB:UB  X  (CANTUS-LENGTH) )) ) 

(PROJECT  MOTE  (LB:U8  1  (CANTUS-LENGTH) ))) 

|  13:15  ---  [by  RULE315]  — > 

((LAMBOA  (PR0JECT1 )  (LEGAL-CANTUS!  PR0JECT1)) 

(PROJECT  NOTE  ( LB : U8  X  (CAMTUS-LENGTH)))) 

(LEGAL-CANTUS!  PROJECTl) 

(  13: 16  ---  [ELABORATE  by  RULE124]  --> 

(ANO  [IN  («  PROJECTX)  ( LB: UB  8  16)] 

[FORALL  INTERVAL1  ( INTERVALS-OF  PROJECTX) 

(USABLE-INTERVAL!  INTERVAL1 ) ] 

[»<  (MELOOIC -  RANGE  PROJECTl)  (MAJOR  10)] 

[»  (^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  l]) 

(COMSIDER-PROP 
((LAMBOA  (PROJECTl) 

(ANO  [IN  (*  PROJECTl)  ( LB : UB  8  IB)] 

[FORALL  INTERVAL1  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTCRVALl)] 


|  13:11 

|  13:12 
|  13:13 

|  13:14 


f 
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[»<  (MELODIC  -  RANGE  PROJECTl)  (MAJOR  10)] 

[«  (^OCCURRENCES  (CLIMAX  PROJECT!)  PROJEC71)  1])) 

(PROJECT  NOTE  (LB:UB  1  (CANTUS-LENGTH))))) 

<  13:17 

---  [SUCCEED  by  RULE313]  — > 

(ACHIEVE  HSM1) 

(HSM1  <-  REFORMULATED-PROBLEM  : 

((LAMBDA  (PR0JECT1) 

(AND  [IN  (»  PROJECT1)  ( LB; UB  8  16)] 

(FORALL  INI ERVAL1  (INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVALl) ] 

[«<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)] 

[*  (NOCCURREMCES  (CLIMAX  PROJECTl)  PROJECTl)  1])) 

(PROJECT  MOTE  ( LB : UB  1  (CANTUS-LENGTH))))) 

HSMI 

13:18  ---  [by  RULE317]  — > 

HSMI 

(HSM1  <-  PATH  :  PROJECTl) 

(HSM1  <-  STEP-OROER  .  NIL) 

(HSMt  <-  STEP-TEST  :  T) 

(HSM1  <-  PATH  ORDER  :  NIL) 

(HSMI  <-  PATH-TEST  :  T) 

(HSM1  <-  SOLUTION-TEST  : 

(LAMBDA  (PROJECTl) 

(ANO  [IN  (#  PROJECTl)  (L8:U8  8  16)] 

[FORALL  INTERVALl  ( INTERVALS-OF  PROOtCTl) 

(USABLE-INTERVAL!  INTERVALl)] 

[»<  (MELODIC  RANGE  PROJECTl)  (MAJOR  10)] 

[»  ^OCCURRENCES  (CLIMAJf  PROJECTl)  PROJECTl)  l]})) 

13:19  ---  [by  RULE378]  — -> 

HSMI 

(HSMI  <-  COMPLETION-TEST  . 

(LAMBOA  (PROJECTl)  (IN  (#  PROJECTl)  ( LB : UB  8  16)))) 

(HSMI  <-  SOLUTION-TEST  ; 

(LAMBDA  (PROJECTl) 

(ANO  [FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVAL’ ) ] 

[«<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)] 

[»  (^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  1]))) 

>  1320  —  [by  RULE323]  — -> 

(CONSIDER-PROP 
(ANO  T 

[LAMBOA  (PROJECTl) 

(«>  (*>  (FORALL  INTERVALl  ( INTERVALS-OF  (PROJECT  NOTE  (LBtUB  1  (CANTUS  LENGTH) ) ) ) 
(USABLE-INTERVAL!  INTERVALl)) 

(FORALL  INTERVAL!  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl) ))]) ) 

(AND  T 

[LAMBDA  (PROJECTl) 

(»>  (*>  (FORALL  INTERVALl  ( THTE RVALS-OF  (PROJECT  NOTE  (LB:U8  l  (CANTUS-LENGTH) ) ) ) 
(USABLE-INTERVAL!  INTERVAL!)) 

(FORALL  INTERVALl  ( INTERVALS  OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))) 

(FORALL  INTERVALl  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl)))]) 

|  13:21  — -  [SIMPLIFY  by  RULE341]  ---> 

(LAMBOA  (PROJECTl) 

(•>  (»>  (FORALL  INTERVALl  (INTERVALS-OF  (PROJECT  NOTE  (LB:U8  1  (CANTUS-LENGTH)))) 
(USABLE-INTERVAL!  INTERVALl)) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl)))) 

(«>  (FORALL  INTERVALl  (INTERVALS-OF  (PROJECT  NOTE  (L8.UB  1  (CANTUS-LENGTH}  ) ) ) 
(USABLE- INTERVAL!  INTERVALl)) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE- INTERVAL!  INTERVALl))) 

|>  13:22  — -  [REDUCE  by  RULE379]  — -> 

(SHOW  (SUBSET  (INTERVALS-OF  PROJECTl) 

(INTERVALS-OF  (PROJECT  NOTE  (LBtUB  1  (CANTUS-LENGTH)))))) 

(SUBSET  (INTERVALS-OF  PROJECTl) 

(INTERVALS-OF  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))))) 

-  [REDUCE  by  RULE30]  — > 


||>  13:23 
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(SHOW  (SUBSET  PR0JECT1  (PROJECT  NOTE  (LB:UB  1  (CANTUS-LENGTH) ) ) ) ) 

||<  13:24  — -  fASSUME  by  RULE221]  — -> 

(SHOW  T) 

((SUBSET  PROJECT!  (PROJECT  ROTE  (L8:U8  1  (CANTUS-LENGTH) ) ) ) 

<-  : 

(->  T  IF 

(-  (SUBSET  PROJECT 1  (PROJECT  ROTE  (IB:UB  1  (CANTUS ~ LENGTH ) ) ) )  T))) 

|<  13:25  —  [SUCCEED  by  RULE53]  ---> 

(CONSIDER'PROP 
( LAM80A  (PROJECT1) 

(->  T 

(FORALl  INTERVAL 2  ( INTERVALS-OF  PROJECT1) 

(USABLE-INTERVAL!  INTERVAL1) ) ) ) ) 

(»>  T 

(FORALL  INTERVAL1  (INTERVALS-OF  PROJECT1) 

(USABLE-INTERVAL!  INTERVAL1 ) ) ) 

|  13:26  —  [SIMPLIFY  by  RULE12]  — -> 

(FORALL  INTERVAL1  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl ) ) 


(CONSIDER-PROP 
(LAMBOA  (PROJECT1) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECT1) 

(USABLE-INTERVAL!  INTERVALl)))) 

<  13:27 

---  [SUCCEED  by  RULE313]  — > 

(ACHIEVE  HSM1) 

(HSNl  <-  PATH-TEST  : 

(LAMBOA  (PROJECT1) 

(FORALL  INTERVALl  (INTERVALSOF  PR0JECT1) 

(USABLE-INTERVAL!  INTERVALl)))) 

HSM1 

>  13:28  — -  [by  RULE327]  ---> 

(SHOW  (>  (FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVALl)) 

(FORALL  II  (INDICES-OF  PROJECTl)  Ql))) 

(INTERVALS-OF  PROJECTl) 

|  13:29  ---  [ELABORATE  by  RULE  124]  ---> 

(DISTRIBUTE  14  (LB:U 8  2  (4  PROJECTl) , 

(INTERVAL  (PROJECTl  (-  14  1))  (PROJECTl  14))) 

(FORALL  INTERVALl 

(DISTRIBUTE  14  (LB:UB  2  (#  PROJECTl)) 

(INTERVAL  (PROJECTl  (-  14  1))  (PROJECTl  I*))) 
(USABLE-INTERVAL!  INTERVALl)) 

|  13.30  ---  [REMOVE-QUANT  by  RULE13]  — -> 

(FORALL  14  (LB: UB  2  (N  PROJECTl)) 

(USABLE -INTERVAL!  (INTERVAL  (PROJECTl  (-  14  1))  (PROJECTl  14)))) 

(*  (FORALL  14  ( LB : UB  2  [0  PROJECTl)) 

(USABLE -INTERVAL!  (INTERVAL  (PROJECTl  (-  14  1))  (PROJECTl  14)))) 
(FORALL  II  ( INDICES-OF  PROJECTl)  Ql)) 

|  13:31  ---  [REDUCE  by  RULE380]  ---> 

C  Ql 

(OR  [USABLE -INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  (PROJECTl  II))] 

[IN  II  (OIFF  ( INDICES-OF  PROJECTl)  ( LB : UB  2  {#  PROJECTl)))])) 

(INDICES-OF  PROJECTl) 

|  13:32  — -  [ELABORATE  by  RULE381]  — -> 

( LB: UB  l  {0  PROJECTl)) 

(OIFF  ( L8 : UB  1  ( 0  PROJECTl))  (18:UB  2  (#  PROJECTl))) 

1  13:33  ---  [REDUCE  by  RULE382]  ---> 

(IB.U8  1  (-  2  1)) 

(-  2  1) 

|  13:34  ---  [COMPUTE  by  RUIE238]  — > 


(LB : UB  1  1) 

t  13:36  ---  [SIMPLIFY  by  RULE 253]  — > 

(SET  1) 

(IN  II  (SET  1)) 

|  13:36  —  [DISTRIBUTE  by  RULE  162]  —  > 

(OR  (-  II  1]) 


♦ 
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|  13:37  —  [SIMPLIFY  by  RULE178]  ---> 

C  I»  ») 

C  Q1 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  (RROJECT1  II))] 

t*  II  1])) 

|  33 : 30  —  [REDUCE  by  RULE  194]  ---> 

T 

(01  <*  BINDING  : 

(OR  [USABLE- INTERVAL*  (INTERVAL  (PROJECT1  (-  II  1))  (PROJECTl  II))] 
t"  II  1])) 

(SHOW  T) 

<  U:39  ---  (SUCCEED  by  RULE34]  —  > 

(ACHIEVE  (THEN  JCONSIDER-PROP  HSM1  STEP-TEST 

(AND  T  [LAMBDA  (II  N0TE1 )  (THEN  SSUBST  NOTEl  (PROJECTl  II)  01)]))) 

(AND  T  [LAMBDA  (IX  NOTEl)  (THEN  SSUBST  NOTEl  (PROJECTl  II)  Ql)]) 

13:«0  — -  [SIMPLIFY  by  RULE341]  — -> 

(LAMBDA  (II  NOTEl)  (THEN  SSUBST  NOTEl  (PROJECTl  II)  Ql)) 

01 

13:41  ---  (EVAL  by  RULE127]  ---> 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  (PROJECTl  II))] 

[•  II  1]) 

(THEN  SSUBST  NOTEl  (PROJECTl  II) 

(OR  (USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  l))  (PROJECTl  It))] 
[■  II  1])) 

13:42  ---  [SIMPLIFY  by  RULE331]  — -> 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  l))  NOTEl)] 

[-  II  l]) 

(THEM  SCONSIDER-PROP  HSM1  STEP-TEST 
(LAMBOA  (11  NOTEl) 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  l))  NOTEl)] 

[•  II  11))) 

13:43  ---  [SIMPLIFY  by  RULE334]  ---> 

HSM1 

(HSM1  <-  STEP-TEST  : 

(LAMBDA  (II  NOTEl) 

(OR  (USABLE -INTERVAL!  (INTERVAL  (PROJECTl  (-  11  1))  NOTEl)] 

[*  II  1]))) 

>  13:44  ---  [by  RULE323]  ---> 

(CONSIDER-PROP 
(AND  (LAMBOA  (PROJECT!) 

(FORALL  INTERVALl  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))] 

[LAMBOA  (PROJECTl) 

(->  (=>  (•<  (MELODIC -RANGE  (PROJECT  NOTE  (LB:UB  1  (CANTUS-LENGTH) ) ) ) 

(MAJOR  10)) 

(•<  (MELODIC -RANGE  PROJECTl)  (MAJOR  10))) 

(»<  (MELOOIC-RANGE  PROJECTl)  (MAJOR  10)))])) 

(->  (■<  (MELODIC-RANGE  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH)))) 

(MAJOR  10)) 

(«<  (MELOOIC-RANGE  PROJECTl)  (MAJOR  10))) 

|>  13:46  ---  [REDUCE  by  RULE 363]  ---> 

(SHOW  («<  (MELOOIC-RANGE  PROJECTl) 

(MELOOIC-RANGE  (PROJECT  NOTE  (LB:U8  1  (CANTUS-LENGTH)))))) 

(•<  (MELOOIC-RANGE  PROJECTl) 

(MELOOIC-RANGE  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))))) 

J|>  13:46  ---  (REDUCE  by  RULE30]  — -> 

(SHOW  (SUBSET  PROJECTl  (PROJECT  NOTE  (LB:U8  1  (CANTUS-LENGTH))))) 

(SUBSET  PROJECTl  (PROJECT  NOTE  (LB: UB  1  (CANTUS-LENGTH)))) 

HI  13:47  ---  [EVAL  by  RULE346]  ---> 


(SHOW  T) 

||<  13:46  — -  [SUCCEED  by  RULE63]  — > 

(SHOW  T) 

|<  13:49  ---  [SUCCEED  by  RULE53]  ---> 

(CONSIDER- PROP 
(ANO  [LAMBOA  (PROJECTl) 

(FORAU  INTERVALl  (INTERVALS-OF  PROJECTl) 
(USABLE -INTERVAL!  INTERVALl))] 
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[LAMBOA  (PROJECTl)  (*>  T  (•<  (MELODIC-RANGE  PROJECT!)  (MAJOR  10)))])) 

(•>  T  (■<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10))) 
|  13:60  ---  (SIMPLIFY  by  RULED]  — 

(*<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)) 

(CONSIOER-PROP 
(AMO  { LAM80A  (PROJECT! ) 

(FORALL  INTERVAL!  ( INTERVALS-OF  PROJECT1) 

(USABLE- INTERVAL!  INTERVAll) )) 

[LAMBDA  (PROJECTl)  (•<  (MELODIC-RANGE  PROJECT1)  (MAJOR  10))))) 

<  13:61 

---  [SUCCEED  by  RULE313]  — -> 

(ACHIEVE  NSM1) 

(HSM1  <-  PATH-TEST  : 

(AND  [ LAMBDA  (PROJECTl) 

(FORALL  INTERVAL1  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVAL1) )) 

[LAMBDA  (PROJECTl)  (■<  ( MELODIC- RANGE  PROJECTl)  (MAJOR  10))))) 


13:52  ---  [REFINE  by  RULE384)  — -> 

(THEN  SCOMSIOER-PROP  HSMl  CHOICE-SETS 
(LAMBDA  (II) 

(SET-OF  NOTEl  (TONES) 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTEl)] 

t-  II  »))))) 

(HSMl  <-  STEP-TEST  :  T) 

(SET-OF  NOTEl  (TONES) 

(OR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTEl)) 

[■  U  1)1) 

13:53  ---  [DISTRIBUTE  by  RULE386]  — > 

(IF  («  II  1) 

(TONES) 

(SET-OF  NOTEl  (TONES) 

(OR  [USA8LE -INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTEl)]))) 

(DR  [USABLE-INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTEl))) 

13  54  ---  [SIMPLIFY  by  RULE  178)  ---> 

(USABLE- INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTEl)) 

(THEN  SCONS  IDE R  - PROP  HSMl  CHOICE-SETS 
(LAMBDA  (II) 

(IF  (•  II  l) 

(TONES) 

(SET-OF  NOTE!  (TONES) 

(USABLE -INTERVAL!  (INTERVAL  (PROJECTl  (-  II  1))  NOTED))))) 

13:56  ---  [RECOGNIZE  by  RULE385]  ---) 

(THEN  JCONSIOER-PROP  HSMl  CHOICE-SETS 
(LAMBOA  (11) 

(IF  (•  II  1)  (TONES)  (USABLE-SUCCESSORS-OF  (PROJECTl  (-  II  l)))))) 

(DEFINE  USABLE-SUCCESSORS-OF  (NOTE2) 

(SET-OF  NOTEl  (TONES)  (USABLE-INTERVAL!  (INTERVAL  N0TE2  NOTEl)))) 

13.55  —  [SIMPLIFY  by  RULE334] - > 

HSMl 

(HSMl  <-  CHOICE -SITS  : 

(LAMBDA  (11) 

(IF  (•  II  1)  (TONES)  (USABLE-SUCCESSORS-OF  (PROJECTl  (-  II  1)))))) 

>  13:57  ---  [by  RULE3U]  —  > 

(CONSIOER-PROP 
(LAMBOA  (PROJECTl) 

(ANO  [FORALL  INTERVAL1  (INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVAL1)] 

[*<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)] 

(•  (^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  1])))  ' 

(■  (NOCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  l) 

)  13:58  ---  [RESTRICT  by  RULE25B)  — > 

(ANO  (•  (CLIMAX  PROJECTl)  CllMAXl] 

[>  (POCCURRENCES  CllMAXl  PROJECTl)  1]) 

(ASSUME  (SELECT  CLIMAX1  (RANGE  (CLIMAX  PROJECTl)))) 

(AND  [FORALL  UTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTCRVALl)) 

[*t  (MELODIC-RANGE  PROJECT!)  (MAJOR  10)) 

(ANO  (•  (CLIMAX  PROJECTl)  CllMAXl) 

[■  (POCCURRENCES  CllMAXl  PROJECTl)  1])) 


» 
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|  13:59  ---  [SIMPLIFY  by  RULE177]  — > 

(AMO  [*  (CLIMAX  PROJECTl)  CLIMAX1] 

['  {^OCCURRENCES  CLIMAX1  PROJECT1)  l] 

[FORALL  INTERVAL!  ( INTERVALS-OF  PROJECT1) 

(USABLE-INTERVAL!  INTERVAL1 ) ] 

[-<  (MELODIC- RANGE  PROJECTl)  (MAJOR  10)]) 

(CLIMAX  PROJECT1) 

l  13:50  —  [ELABORATE  by  RULE124]  - > 

(HIGHEST  PROJECTl) 

|  13:61  ---  [ELABORATE  by  RULE124]  — > 

(THE  Cl  PROJECTl  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  Cl)))) 

(-  (THE  Cl  PROJECTl  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  Cl)))) 
CL IMAX1 ) 

|  13.62  ---  [REMOVE-QUANT  RULE131]  - > 

(AND  [IN  CLIMAX1  PROJECTl] 

[FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CIIMAX1))]) 

(AND  [ANO  [IN  CLIMAX1  PROJECTl] 

[FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAX1))]] 

('  {^OCCURRENCES  CLIMAX1  PROJECTl)  1] 

[FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl)] 

[*<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)]) 

|  13:63  — -  [SIMPLIFY  by  RULE  177]  ---> 

(ANO  [IN  CLIMAX1  PROJECTl] 

[FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAX1))] 

[■  (^OCCURRENCES  CLIMAX!  PROJECTl)  l] 

[FORALL  INTERVALl  ( INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVALl)] 

[><  (MELODIC-RANGE  PROJECTl)  (MAJOR  10)]) 

(CONSIOER-PROP 
(LAMBOA  (PROJECTl) 

(AND  [IN  CLIMAX1  PROJECTl) 

[FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAX1))] 

£»  (^OCCURRENCES  CLIMAX1  PROJECTl)  l] 

(FORALL  INTERVALl  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl)] 

[«<  (MELODIC -RANGE  PROJECTl)  (MAJOR  10)]))) 

<  13:64 

---  [SUCCEED  by  RULE313]  --> 

(ACHIEVE  HSM1) 

(HSM1  <-  SOLUTION- TEST  : 

(LAMBDA  (PROJECTl) 

(ANO  [IN  CLIMAXl  PROJECTl] 

[FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAXl))] 

[•  (^OCCURRENCES  CLIMAXl  PROJECTl)  1] 

[FORALL  INTERVALl  (INTERVALSOF  PROJECTl) 

(USA8LE- INTERVAL!  INTERVALl)] 

[«<  (MELODIC- RANGE  PROJECTl)  (MAJOR  10)]))) 

HSN1 

>  13:65  ---  [by  RULE323]  ---> 

(CONSIDER-PROP 

(ANO  [ANO  [LAMBOA  (PROJECTl) 

(FORALL  INTERVALl  (INTERVALS-Of  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))] 

(LAMBDA  (PROJECTl)  (■<  ( MELODIC -RANGE  PROJECTl)  (MAJOR  10))]] 

(LAMBDA  (PROJECTl) 

(•>  (->  (FORALL  XI  (PROJECT  NOTE  ( LB : UB  1  (CAN TUS-LENGTH) ) ) 

(NOT  (HIGHER  XI  CLIMAXl))) 

(FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAXl)))) 

(FORALL  XI  PROJECTl  (NOT  (HIGHER  Xt  CUMAXl ) ) ) )})) 

(AND  (AND  [LAMBOA  (PROJECTl) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVALl))] 

[LAMBDA  (PROJECTl)  (•<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10))]] 
[LAMBOA  (PROJECTl) 

(->  (->  (FORALL  XI  (PROJECT  NOTE  ( LB: UB  1  ( C AN TU$- L£ NG TM) )) 

(NOT  (HIGHER  XI  CLIMAXl))) 

(FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAXl)))) 

(FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAXl))))]) 

|  13:66  ---  [SIMPLIFY  by  RULE177]  — > 

(ANO  [LAMCOA  (PROJECTl) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))] 

[ LAMBDA  (PROJECTl)  (•<  (MELOOIC- RANGE  PROJECTl)  (MAJOR  10))] 
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[UNBOA  (PROJECT!) 

(•>  (■>  (FORALl  XI  (PROJECT  ROTE  (LB: OS  1  (CANTUS-LENGTH) ) ) 

(NOT  (HIGHER  XI  CL1MAX1))) 

(FORALL  XI  PROJECTI  (NOT  (HIGHER  XI  CLIMAX1)))) 

(FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX!))))]) 

(•>  (FORALL  Xl  (PROJECT  NOTE  (LB: UB  1  (CANTUS-LENGTH ) ) ) 

(NOT  (HIGHER  XI  CLIMAX1))) 

(FORALL  XI  PROJECT  1  (NOT  (HIGHER  XI  CLIMAX1)))) 

|>  13:67  — -  [REDUCE  by  RULE379]  — > 

(SHOW  (SUBSET  PROJECT!  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))))) 

(SU6SET  PROJECT!  (PROJECT  NOTE  (L8:UB  t  (CANTUS-LENGTH) )) ) 
||  13: 6i  — -  [EVAL  by  RULE348]  — > 

T 

(SHOW  T) 

|<  13:69  —  [SUCCEED  by  RULE63]  — > 

(CONSIDER-PROP 
(AND  [LAMBDA  (PROJECT1) 

(FORALL  INTERVAL1  ( INTERVALS-OF  PROJECTi) 

(USABLE-INTERVAL!  INTERVAL1 ) )] 

[LAMBDA  (PROJECTI)  (■<  (MELODIC-RANGE  PROJECTI)  (MAJOR  10))] 

(LAMBDA  (PROJECTI) 

(»>  T  (FORALL  XI  PROJECT!  (NOT  (HIGHER  XI  CLIMAXl)) ) )])) 

(•>  T  (FORALL  XI  PROJECTI  (NOT  (HIGHER  XI  CLIMAXl)))) 

|  13:70  ---  [SIMPLIFY  by  RULE12]  ---> 

(fORALL  XI  PROJECTI  (NOT  (HIGHER  XI  CLIMAXl))) 

(CONSIDER-PROP 
(ANO  [LAMBOA  (PROJECTI) 

(FORALL  INTERVAL1  (INTERVALS-OF  PROJECTI) 

(USABLE- INTERVAL!  INTERVAL1 ) )  ] 

[LAMBOA  (PROJECTI)  ( »<  (MELOOIC  RANGE  PROJECTI)  (MAJOR  10))] 

[LAMBOA  (PROJECTI)  (fORALL  XI  PROJECTI  (MOT  (HIGHER  XI  CLIMAXl)))])) 

<  13:71 

—  [SUCCEED  by  RULE 3 13]  — -> 

(ACHIEVE  HSM1) 

( HSM1  <-  PATH-TEST  : 

(ANO  [LAM8DA  (PROJECTI) 

(FORALL  INTERVAL1  (INTERVALS-OF  PROJECTI) 

(USABLE- INTERVAL!  INTERVAL l ) )] 

[LAMBDA  (PROJECTI)  (■<  (MELODIC-RANGE  PROJECTI)  (MAJOR  10))] 

[LAMBDA  (PROJECTI)  (FORALL  Xl  PROJECTI  (NOT  (HIGHER  Xl  CLIMAXl)))])) 

HSM1 

>  13:72  ---  [by  RULE327)  ---> 

(SHOW  (-  (FORALL  Xl  PROJECTI  (NOT  (HIGHER  Xl  CLIMAXl))) 

(FORALL  ri  ( INOICES-OF  PROJECTI)  Q2))) 

(FORALL  Xl  PROJECTI  (NOT  (HIGHER  Xl  CLIMAXl))) 

|  13:73  ---  [by  RULE328]  — > 

(FORALL  15  (INDICES-OF  PROJECTI) 

(NOT  (HIGHER  (PROJECTI  15)  CLIMAXl))) 

(-  (FORALL  15  (INOICES-OF  PROJECTI) 

(NOT  (HIGHER  (PROJECTI  15)  CLIMAXl))) 

(FORALL  II  (INDICES-OF  PROJECTI)  Q2)) 

|  13:74  ---  [REDUCE  by  RULE  192]  — > 

(-  (NOT  (HIGHER  (PROJECTI  II)  CLIMAXl))  Q2) 

|  13:76  ---  [EVAL  by  RULE271]  — > 

T 

(Q2  <-  BINDING  :  (NOT  (HIGHER  (PROJECTI  II)  CLIMAXl))) 

(SHOW  T) 

<  13:75  ---  [SUCCEED  by  RULE34]  ---> 

(ACHIEVE  (THEN  SCONSIDER-PROP  HSM1  STEP-TEST 

(AND  T  [LAMBDA  (11  NOTEO)  (THEN  SSUBST  NOTE3  (PROJECTI  !l)  Q2)]))) 

(AMD  T  [LAMBDA  (II  NOTE3)  (THEN  SSUBST  NOTE 3  (PROJECTI  II)  02)]) 

13:77  —  [SIMPLIFY  by  RULE341]  *--> 

(LAMBDA  (II  NOTE3)  (THEN  SSUBST  NOTE3  (PROJECTI  II)  Q2)) 

02 

13:78  ---  [EVAL  by  RULE127]  ---> 

(NOT  (HIGHER  (PROJECTI  II)  CLIMAXl)) 

(THEN  SSUBST  NOTE3  (PROJECTI  II) 

(NOT  (HIGHER  (PROJECTI  II)  CLIMAXl))) 
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33.  J9  — -  [SIMPLIFY  by  RULE331]  — > 

(MOT  (HIGHER  MOT£3  CLIMAX!)) 

(THEM  SC ONSIOER- PROP  HSM1  STEP-TEST 

( LAMBDA  (It  MOTE3)  (MOT  (HIGHER  MOTES  CLIMAX!)))) 
13 : SO  ---  (SIMPLIFY  by  RULE334]  ---> 

HSM1 

(HSM1  <-  STEP-TEST  ( LAM80A  (11  MOTES)  (MOT  (HIGHER  MOTES  CLIMAX!)))) 


>  13:  SI  — *  [by  RULE312]  —  > 

(CONSIOER-PROP 
( LAMBDA  (PROJECT1 ) 

(AMO  [IM  CLIMAX1  PROJECT1] 

(FORAU  XI  PROJECT1  (MOT  (HIGHER  XI  CL1MAX1))] 
[•  (40CCURREMCES  CLIMAX1  PROJECT1)  1] 

[FORALL  INTERVAL!  ( IMTERVALS-OF  PROJECT1) 
(USABLE-INTERVAL!  IMTERVAL1 ) ] 

(■<  (MELODIC ' RAMGE  PROJECT!)  (MAJOR  10)]))) 


(•  (^OCCURRENCES  CLIMAX!  PR0JECT1)  1) 
|>  13:82  — *  [by  RULE268]  —  > 

(CONSIDER  (<  (^OCCURRENCES  CLIMAX!  PROJECT!)  !)) 


(.  (^OCCURRENCES  CLIMAX1  PR0JECT1)  1) 
ij  \3-33  ---  [ELABORATE  by  RULESAO]  --> 

(AMO  [!■  (MOCCURRENCES  CLIMAX1  PR0JECT1)  1] 

[>.  1  (MOCCURRENCES  CL1MAX1  PR0JECT1)]) 

^OCCURRENCES  CLIMAX!  PR0JECT1) 

33 . 34  ---  [ELABORATE  by  RULE  124]  — -> 

(4  (SET-OF  X2  PR0JECT1  (■  X2  CLIMAX1))) 

(>*  (»  (SET-OF  X2  PROJECT!  (»  X2  CLIMAX1)))  1) 
M  33  g5  ---  (RECOGNIZE  by  RULE387]  ---> 

'  (EXISTS  X2  PR0JECT1  (*  XZ  CLIMAX1)) 

,,  33 ; 38  —  (RECOGNIZE  by  RULE292]  — > 

(IN  CLIMAX!  PR0JECT1) 

(>•  1  (fOCCURRCNCES  CLIMAX1  PR0JECT1)) 

||  33:8!  [by  RULE  133]  — 

(•<  (MOCCURREMCES  CLIMAX!  PROJECT!)  1) 

(COMSIOER  (ANO  [IM  CLIMAX!  PR0JECT1] 

[•<  (MOCCURREMCES  CLIMAX1  PR0JECT1)  !])) 

|<  33:88  [by  RULE288)  — > 

(CONSIDER-PROP 
(LAMBDA  (PROJECT!) 

(ANO  (IN  CLIMAX!  PROJECT!] 

(FORALL  *1  PROJECT!  (NOT  (HIGHER  X!  CLIMAX1))] 

[ANO  (IN  CLIMAX1  PR0JECT1] 

[•<  (MOCCURREMCES  CLIMAX1  PR0JECT1)  1]] 

[FORALL  INTERVAL1  ( INTERVALS-OF  PROJECT!) 

(USABLE-INTERVAL!  INTERVAL!)] 

[«<  (MELODIC-RANGE  PROJECT!)  (MAJOR  10)]))) 


(ANO  [IN  CLIMAX!  PROJECT1] 

[FORALL  XI  PROJECT!  (MOT  (HIGHER  XI  CLJMAX1))] 
[AND  [IM  CLIMAX1  PROJECT!] 

[«<  (MOCCURRENCES  CLIMAX!  PROJECT!)  1]] 
[FORALL  INTERVAL1  (INTERVALS-OF  PROJECT!) 

(USABLE -INTERVAL!  INTERVAL1 ) ] 

(.<  (MELOOIC-RANGE  PR0JECT1)  (MAJOR  10)]) 

|  33.88  ---  [SIMPLIFY  by  RULE1ZT]  — > 

(AMO  [IN  CLIMAX!  PROJECT1] 

[•<  (MOCCURREMCES  CLIMAX!  PROJECT1)  1] 

[IN  CLIMAX!  PROJCCT1] 

[FORALL  X!  PROJECT1  (MOT  (HIGHER  XI  CLIMAX!))] 
[FORALL  INTERVAL1  (INTERVALS-OF  PROJECT!) 

(USABLE -INTERVAL!  INTERVAL!)] 

[•<  (MELOOIC-RANGE  PROJECT1)  (MAJOR  10)]) 

I  33-90  ---  (SIMPLIFY  by  RULE  188]  — > 

(ANO  (IM  CLIMAX!  PROJECT!] 

[.<  (MOCCURRENCES  CIINAX1  PROJECT1)  l] 

(FORALL  X!  PROJECT!  (NOT  (HIGHER  XI  CLIHAX1))] 
[FORALL  IMTERVAL1  ( IN! E RVAL5  OF  PROJCCTl) 
(USABLE-INTERVAL'  IMTERVAll)] 

[.<  (MELOOIC-RANGE  PROJECT!)  (MAJOR  10)]) 


(CONSIOER-PROP 
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( LAMBDA  (PROJECTl) 

(AMO  [U  CLIMAX1  PROJECT!] 

[*<  ( ^OCCURRENCES  CLIMAXl  PROJECTl)  1] 

[FORALL  XI  PROJECT1  (NOT  (HIGHER  XI  CLIMAXl))] 

[FORALL  INTERVALl  (INTERVALS-OF  PROJECT1) 

(USABLE 'INTERVAL!  INTERVALl)] 

[-<  (MELODIC* RANGE  PROJECT1)  (MAJOR  10)]))) 

<  13:91 

—  [SUCCEED  by  RULE 3 13]  — > 

(ACHIEVE  HSM1 ) 

(HSM1  <-  SOLUTION-TEST  : 

(LAMBDA  (PROJECT1) 

(AND  [IN  CLIMAX  1  PROJECT!] 

[»<  (^OCCURRENCES  CLIMAX1  PROJECT1)  1] 

[FORALL  XI  PROJECT 1  (NOT  (HIGHER  XI  CLIMAX1))] 

[FORALL  INTERVALl  ( INTERVALS-OF  PROJECT!) 

(USABLE -INTERVAL!  INTERVALl)] 

[»<  (MELODIC  -  RANGE  PROJECT1)  (MAJOR  10)]))) 

HSM1 

>  13:92  ---  [by  RULE323]  — > 

(CONSIDER-PROP 

(AND  [AND  [LAMBOA  (PROJECT!) 

(FORALL  INTERVALl  ( IMTERVALSOF  PROJECT!) 

(USABLE -INTERVAL!  INTERVALl))] 

[LAMBDA  (PROJECT!)  (*<  (MELODIC- RANGE  PROJECT1)  (MAJOR  10))] 

[LAMBDA  (PROJECT  1 )  (FORALL  XI  PROJECT1  (NOT  (HIGHER  XI  CLIMAX!)))]] 

[LAMBOA  (PROJECTl ) 

(«>  (*>  (»<  (^OCCURRENCES  CLIMAX1  (PROJECT  NOTE  (LB: UB  l  (CANTUS-LENGTH) ) ) ) 

1) 

(»<  (^OCCURRENCES  CLIMAX!  PROJECTl)  1)) 

(*<  (<V OCCURRENCES  CLIMAX1  PROJECTl)  1))])) 

(■>  (-<  (^OCCURRENCES  CLIMAXl  (PROJECT  NOTE  (LB:UB  l  (CANTUS-LENGTH)))) 
1) 

(»<  (fOCCURRENCES  CLIMAXl  PROJECTl)  1)) 

|>  13:93  ---  [REDUCE  by  RULE383]  ---> 

(SHOW  (*<  (^OCCURRENCES  CLIMAXl  PROJECTl) 

(^OCCURRENCES  CLIMAXl  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH)))))) 

( ^OCCURRENCES  CLIMAXl  PROJECTl) 


||  13:94 

---  [ELABORATE  by  RULE  124]  --> 

(N  (SET-OF  X3  PROJECTl  (»  X3  CLIMAX!))) 

||  13:96 

(fOCCURRENCES  CLIMAXl  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH) ) ) ) 
- [ELABORATE  by  RULE  124]  ---> 

(*  (SET-OF  X4  (PROJECT  NOTE  ( LB : UB  1  (CANTUS-LENGTH))) 

(*  X4  CLIMAXl ) ) ) 

||>  13:96 

(•<  (P  (SET-OF  X3  PROJECTl  (»  X3  CLIMAXl))) 

(#  (SET-OF  X4  (PROJECT  NOTE  ( LB : UB  l  (CANTUS-LENGTH))) 

(*  X4  CLIMAXl)))) 

---  [REOUCE  by  RULE30]  — -> 

(SHOW  (SU8SET  (SET-OF  X3  PROJECTl  («  X3  CLIMAXl)) 

(SET-OF  X4  (PROJECT  NOTE  ( LB: UB  1  (CANTUS-LENGTH))) 

(-  X4  CLIMAXl)))) 

|||>  13:97 

(SUBSET  (SET-OF  X3  PROJECTl  (•  X3  CLIMAXl)) 

(SET-OF  X4  (PROJECT  NOTE  ( LB : UB  l  (CANTUS-LENGTH))) 

(-  X4  CLIMAXl))) 

---  [REOUCE  by  RULE388]  — -> 

(SHOW  (SU8SET  PROJECTl  (PROJECT  NOTE  (LB : UB  l  (CANTUS-LENGTH))))) 

INI  13:»« 

(SUBSET  PROJECTl  (PROJECT  NOTE  (L8:UB  1  (CANTUS-LENGTH)))) 

---  [EVAL  by  RULE346]  — -> 

T 

|||<  13:99 

(SHOW  T) 

---  [SUCCEED  by  RULE83]  — > 

(SHOW  T) 

||<  13:100 

—  (SUCCEED  by  RULE 53]  — -> 

(SHOW  T) 

)<  13:101 

---  [SUCCEED  by  RULE53]  --> 

(CONSIOER-PROP 


(AND  [ANO  [LAMBOA  (PROJECTl) 

(FORALL  INTERVALl  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVALl))] 

(LAMBOA  (PROJECTl)  (*<  (MELOOIC- RANGE  PROJECTl)  (MAJOR  10))] 

[LAMBOA  (PROJECTl)  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAXl)))]] 
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[LAMBDA  (PROJECTl)  («>  T  (•<  (•OCCURRENCES  ClIMAXl  PROJECTl)  l))])) 

(•>  T  («<  (•OCCURRENCES  CLIMAX1  PROJECTl)  l)) 

|  13:102  ---  [SIMPLIFY  by  RULE  12  ]  — -> 

(><  (•OCCURRENCES  CLIMAXl  PROJECTl)  1) 

(AND  [ANO  [LAMBOA  (PROJECTl) 

(FORALL  INTERVAL1  ( INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVAll))] 

[LAMBDA  (PROJECTl)  («<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10))] 

[LAMBDA  (PROJECTl)  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAX1 ) ) ) ]] 
[LAMBOA  (PROJECTl)  (><  (•OCCURRENCES  CLIMAX1  PROJECTl)  1)]) 

|  13:103  — -  [SIMPLIFY  by  RULE177]  — > 

(ANO  [LAMBDA  (PROJECTl) 

(FORALL  INTERVAL1  (INTERVALS-OF  PROJECT!) 

(USABLE-INTERVAL!  INTERVAll))] 

[LAMBOA  (PROJECTl)  (-<  ( MELOOIC - RANGE  PROJECTl)  (MAJOR  10))] 

[LAMBOA  (PROJECTl)  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  ClIMAXl)))] 
[LAMBOA  (PROJECTl)  (•<  (•OCCURRENCES  CLIMAX1  PROJECTl)  1)]) 


(CONSIDER-PROP 
(ANO  [LAMBDA  (PROJECTl) 

(FORALL  INTERVAll  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVAll))] 

[LAMBOA  (PROJECTl)  (»<  ( MELOOIC- RANGE  PROJECTl)  (MAJOR  10))] 

[LAMBDA  (PROJECTl)  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  ClIMAXl)))] 

[LAMBDA  (PROJECTl)  (><  (•OCCURRENCES  CLIMAX1  PROJECTl)  1)])) 

<  13:104 

---  [SUCCEED  by  RULE313]  ---> 

(ACHIEVE  HSM1) 

(HSM1  <  PATH -TEST  : 

(AND  [LAMBOA  (PROJECTl) 

(FORALL  INTERVAll  (INTERVALS-OF  PROJECTl) 

(USABLE-INTERVAL!  INTERVAll))] 

[LAMBOA  (PROJECTl)  (*<  (MELODIC-RANGE  PROJECTl)  (MAJOR  10))] 

[LAMQOA  (PROJECTl)  (FORALL  XI  PROJECTl  (NOT  (HIGHER  XI  CLIMAX1)))] 

[LAMBOA  (PROJECTl)  (*<  (•OCCURRENCES  CLIMAX1  PROJECTl)  1)])) 

HSM1 

13:106  ---  [REFINE  by  RULE389]  — -> 

(THEN  {CONSIDER -PROP  MSM1  STEP-TEST 
(LAMBDA  (II  NOTE 3) 

(ANO  [NOT  (HIGHER  N0TE3  ClIMAXl)] 

[»<  (•OCCURRENCES  CLIMAX1  (APPEND  PROJECTl  (LIST  NOTE3)))  1]))) 

(•OCCURRENCES  ClIMAXl  (APPEND  PROJECTl  (LIST  NOTES) ) ) 

—  [DISTRIBUTE  by  RULE284]  -  — > 

(♦  (•OCCURRENCES  CLIMAX1  PROJECTl) 

(•OCCURRENCES  CLIMAXl  (LIST  NOTE3 ) ) ) 

(«<  (♦  ( ^OCCURRENCES  CLIMAXl  PROJECTl) 

(•OCCURRENCES  ClIMAXl  (LIST  NOTE3 ) ) ) 

1) 

---  [REDUCE  by  RULE301]  — > 

(IF  (*  ClIMAXl  NOTE3) 

(=<  (•OCCURRENCES  CLIMAX1  PROJECTl)  0) 

(*<  (•OCCURRENCES  CLIMAX1  PROJECTl)  1)) 

(THEN  {CONSIDER- PROP  HSMl  STEP -TEST 
(LAMBDA  (II  NOTES) 

(AND  [NOT  (HIGHER  NOTE3  ClIMAXl)] 

[IF  (»  ClIMAXl  N0TE3) 

(•<  (•OCCURRENCES  ClIMAXl  PROJECTl)  0) 

(•<  (•OCCURRENCES  ClIMAXl  PROJECTl)  1)]))) 

13:108  — -  [EVAL  by  RULE390]  — -> 

(THEN  SCONSIOER -PROP  HSMl  STEP-TEST 
(LAMBOA  (11  NOTES) 

(AND  [NOT  (HIGHER  NOTE3  ClIMAXl)] 

[IF  (•  CLIMAX1  NOTES)  (»<  (•OCCURRENCES  CLXMAX1  PROJECTl)  0)  T] ) ) ) 

(IF  (•  ClIMAXl  NOTES )  (-<  (•OCCURRENCES  CLIMAX1  PROJECTl)  0)  T) 
13:109  ---  [RECOGNI2E  by  RULE391]  — -> 

(OR  [NOT  (■  CLIMAX1  NOTES )] 

[«<  (•OCCURRENCES  CLIMAX1  PROJECTl)  0]) 

(■<  (•OCCURRENCES  CLIMAX1  PROJECTl)  0) 

>  13:110  ---  [by  RUIE288]  ---> 

(CONSIDER  (•<  (•OCCURRENCES  CL  IMA  XI  PROJECTl)  0)) 


13:108 


13:107 


|  13:111 


('<  (•OCCURRENCES  ClIMAXl  PROJECTl)  0) 
---  [RECOGNIZE  by  RULE392]  ---> 
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(*  ( ^OCCURRENCES  CLIMAXl  PROJECTl)  0) 

(tOCCUPRIKCtS  CUMAX I  PROJECTl) 

|  13:112  — -  [ELABORATE  by  RULE124]  — > 

{0  (SET-OF  X5  PROJECT  1  (-  X6  CLIMAXl))) 

(*  ( 0  ISET-OF  X5  PR0JECT1  (»  X6  CLXMAX1 ) ) )  01 
|  13:113  —  [RECOGNIZE  by  RULE291]  — > 

(NOT  (EXISTS  X6  PROJECT1  (*  X5  CLIMAX!))) 

(EXISTS  X5  PROJECT1  (*  XS  CLIMAX!)) 

|  13:114  — v  [RECOGNIZE  by  RULE292]  — > 

(IN  CLIMAXl  PROJECT1) 

(CONSIDER  (NOT  (IN  CLIMAX1  PROJECT1))) 

<  13:115  — -  [by  RULE259]  — > 

(ACHIEVE  (THEM  JC0MSIDER-PRQP  H$M1  STEP-TEST 
(LANBOA  (II  NOTE3) 

(AMD  [MOT  (HIGHER  N0TE3  CLIMAXl)] 

[OR  [NOT  (*  CLIMAX l  NOTE3 ) ]  [NOT  (IN  CLIMAXl  PROJECTl ) ]]) ) ) ) 

(THEN  SCOMSIDER-PROP  HSM1  STEP-TEST 
(LAMBDA  (II  NOTE3) 

(ANO  [NOT  (HIGHER  NQTE3  CLIMAXl)] 

[OR  [NOT  (*  CLIMAXl  N0TE3 ) ]  [NOT  (IN  CLIMAXl  PROJECTl) ]]) ) ) 
13:115  — -  [SIMPLIFY  by  RULE334]  — -> 

HSM1 

(HSM1  <-  STEP* TEST  . 

(LAMBOA  (II  NOTE 3) 

(ANO  [NOT  (HIGHER  MOTE3  CLIMAXl)] 

[OR  [NOT  (-  CLIMAXl  NOTE3)]  [NOT  (IN  CLIMAXl  PROJECTl)]]))) 

[Final  «*pra**1on:] 

(ACHIEVE  HSM1) 

(ASSUMING  (SELECT  CLIMAXl  (RANGE  (CLIMAX  PROJECTl)))) 

(ASSUMING  (SUBSET  PROJECTl  (PROJECT  NOTE  (LB-.UB  1  (CANTUS-LENGTH ) ) ) ) ) 

NIL 

<7>p  ftsfll 

(HSM1  WITH  (PROBLEM  :  ( LEGAL-CANTUS!  (CANTUS))) 

(OBJECT  .  (CANTUS)) 

( CHOICE ~SE0  : 

(EACH  11  ( LB : U8  1  (CANTUS-LENGTH)) 

(CHOOSE  (NOTE  II)  (TONES)  (NOTE  II)))) 

(SEQUENCE  :  NOTE) 

(CHOICES  (PROJECT  NOTE  (LB.UB  1  (CANTUS-LENGTH)))) 

(CHOICE-SETS  : 

(LAMBDA  (II) 

(IF  (•  It  1) 

(TONES) 

(USABLE-SUCCESSORSOF  (PROJECTl  (-  II  l)))))) 

(INDICES  :  ( LB : UB  l  (CANTUS-LENGTH) )) 

(INDEX  .  II) 

(VARIABLES  :  NIL) 

(BINDINGS  :  NIL) 

(INITIAL-PATH  :  NIL) 

(COMPLETION-TEST  ; 

(LAMBOA  (PROJECTl)  (IN  (0  PROJECTl)  (LB:UB  8  18)))) 

( REFORMULATED- PROBLEM  : 

((LAMBDA  (PROJECTl) 

(ANO  [IN  (0  PROJECTl)  (LB.UB  8  15)] 

[FORALL  INTERVAL l  ( INTERVALS-OF  PROJECT!) 

(USABLE-INTERVAL!  INTERVALl) ] 

[»<  (MELOOIC-RANGE  PROJECTl)  (MAJOR  10)] 

[*  ( ^OCCURRENCES  (CLIMAX  PROJECTl)  PROJECTl)  l])) 

(PROJECT  MOTE  (LB.UB  1  (CANTUS-LENGTH) )) ) ) 

(PATH  PROJECTl) 

( STEP'OROCR  :  NIL) 

(STfP-TEST  : 

(LAMBOA  (II  N0TE3) 

(ANO  [NOT  (HIGHER  NOTES  CLIMAXl)] 

[OR  [MOT  (-  CLIMAXl  NOTES)] 

[NOT  (IN  CLIMAXl  PROJECT!)]]))) 

(PATH-OROER  :  NIL) 

(PATH-TEST  : 

(ANO  [LAMBDA  (PROJECT!) 

(FORALL  INTERVALl  ( INTERVALS-OF  PROJECTl) 

(USABLE -INTERVAL!  INTERVALl))] 

[LAMBOA  (PROJECTl) 
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C<  (melooic* range  projecti)  (major  io))] 

[LAMflOA  (PROJECTI) 

(FORALL  XI  PROJECTI  (NOT  (HIGHER  Xl  CLIMAX!)))] 
[LAMBDA  (PROJECTI) 

(*<  (^OCCURRENCES  CLIMAX1  PROJECTI)  l)])) 

(SOLUTION-TEST  : 

(LAMBDA  (PROJECTI) 

(AND  [IN  CLIMAX1  PROJECTI] 

[*<  (^OCCURRENCES  CLIMAX1  PROJECTI)  1] 

[FORALL  XI  PROJECTI  (NOT  (HIGHER  XI  CLIMAX1))] 

[FORALL  INTERVAL!  ( INTERVALS-OF  PROJECTI) 

(USABLE- INTERVAL!  INTERVALl ) ] 

£»<  (MELODIC-RANGE  PROJECTI)  (MAJOR  10)]))))  . 

HSM1 

<8>pp  u**bla-successors-of 

(D£  USABLE -SUCCESSORS -OF  (NOTE2) 

(SIT-OF  NOTE  1  ( TONE j )  ( USABLE - INTERVAL!  (INTERVAL  NOTE2  NOTE  1) ) ) ) 


NIL 

<9>racordf 11a 

RECORD  FILE  OSK:  (013007  .  PZG)  CLOSED  07-DEC-80  19:42:51 
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RECORO  FILE  OSK:  (014007  .  PZG)  OPENED  07-DEC-B0  19:46:59 
NR 

<23>p-11nks  nit 

(DERIV14  STARTED  "01-JUL-80  03:06:01"  /RINKS  NIL  --DOMAIN:  MUSIC 

--PROBLEM:  (ACHIEVE  (’  (^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  l))) 


[Initial  a/tprasi  fon  :  ] 

(ACHIEVE  (*  (^OCCURRENCES  (CLIMAX  CANTUS)  CANTUS)  1)) 

---  [by  RULE268]  — -> 

(FORALL  T1  ( LB: UB  0  (-  (#  CANTUS)  l)) 

((ACHIEVE  («  ( ^OCCURRENCES  (CLIMAX  ( LAMBOA  (JI)  (PREFIX  CANTUS  Jl))) 
(LAMBDA  (01)  (PREFIX  CANTUS  Jl))) 

D> 

Tl)) 


> 


14:2 


(ACHIEVE  (*  (^OCCURRENCES  (CLIMAX 
(LAMBOA 


«n 

---  [by  RULE263]  ---> 

(CONSIOER  (ACHIEVE  {*  (fOCCURRENCES  (CLIMAX 

( LAMBOA 


1))) 


(LAMBDA  (Jl)  (PREFIX  CANTUS  Jl))) 
(Jl)  (PREFIX  CANTUS  Jl))) 


(LAMBOA  (Jl)  (PREFIX  CANTUS  Jl))) 
(Jl)  (PREFIX  CANTUS  Jl))) 


|  14:3 


(LAMBDA  (Jl)  (PREFIX  CANTUS  Jl)) 
—  -  [RECOGNIZE  by  RULE287]  ---> 
CANTUS- l 


|  14:4 


(LAMBDA  (Jl)  (PREFIX  CANTUS  Jl)) 
---  [RECOGNIZE  by  RULE257]  ---> 
CANTUS- 1 


(ACHIEVE  («  (^OCCURRENCES  (CLIMAX  CANTUS- l)  CANTUS- 1)  1)) 

(  14:5  ---  [by  RULE282]  ---> 

(NEXT  (>  (^OCCURRENCES  (CLIMAX  CANTUS- l)  CANTUS-l)  1)) 

\  14:8  ---  [REDUCE  by  RULE283]  — -> 

(■  (NEXT  (/TOCCURRENCES  (CLIMAX  CANTUS-l)  CANTUS-l))  1) 

(NEXT  ^OCCURRENCES  (CLIMAX  CANTUS-l)  CANTUS- 1)) 

|  14:7  ---  [REDUCE  by  RULE283]  — > 

(fOCCURRENCES  (NEXT  (CLIMAX  CANTUS-l))  (NEXT  CANTUS-t)) 


|  14:8 


(-  (fOCCURRENCES  (NEXT  (CLIMAX  CANTUS-l))  (NEXT  CANTUS-l))  1) 
---  [DISTRIBUTE  by  ROLE276]  — -> 

(OR  [AMO  [NOT  (CHANGE  (CLIMAX  CANTUS-l))] 
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1>  14:9 

\\  w-w 

II  14:11 
II  14:12 

||  14: U 

II  14:14 

||  14:15 

||  14:16 

II  14=17 

II  14  13 

II  14:19 

||  1420 
II  14:21 

II  14:22 

U  14:23 

U  14:24 

II  14:28 

||  14:26 


[•  (^OCCURRENCES  (CLIMAX  CANTUS' 1)  (NEXT  CANTUS-1))  l]] 

[ANO  [CHANGE  (CLIMAX  CANTJS-1)] 

[»  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS*!))  (NEXT  CANTUS*!))  1]]) 


(■  (^OCCURRENCES  (CLIMAX  CANTUS*!)  (NEXT  CANTUS-1))  1) 
—  -  [by  RULE268]  — > 

(CONSIDER  (-  (^OCCURRENCES  (CLIMAX  CANTUS-1)  (NEXT  CANTUS-1))  1)) 


(NEXT  CANTUS-1) 

---  (ELABORATE  fry  RULE  124]  -*-> 

( LAMBDA  (J)  (CANTUS* l  (♦  J  1))) 

(CANTUS-1  (♦  J  1)) 

---  (ELABORATE  by  RULE  124]  — > 

(PREFIX  CANTUS  (♦  J  1)) 

---  [ELABORATE  by  RULE274]  — -> 

(APPEND  (PREFIX  CANTUS  J)  (LIST  (NTH  CANTUS  (♦  J  1)))) 

(lAMBOA  (J)  (APPEND  (PREFIX  CANTUS  J)  (LIST  (NTH  CANTUS  (*  J  1))))) 
—  [by  RULE393]  —  > 

(APPENO  (LAMBDA  (J)  (PREFIX  CANTUS  J)) 

(LAMBDA  (J)  (LIST  (NTH  CANTUS  (♦  J  1))))) 

( LAMBDA  (J)  (PREFIX  CANTUS  J)) 

---  (RECOGNIZE  by  RULE267]  — > 

CANTUS-1 


(NTH  CANTUS  (♦  J  1)) 

—  (RECOGNIZE  by  RULE  123]  ---> 

(NOTE  (♦  J  1)) 

(LAMBDA  (J)  (LIST  (NOTE  (♦  J  1)))) 

---  [by  RULE393]  ---> 

(LIST  (LAMBDA  (J)  (NOTE  (♦  J  1)))) 

(LAMBDA  (J)  (NOTE  (♦  J  l))) 

—  [RECOGNIZE  by  RULE  123]  — > 

(NEXT  NOTE) 

(^OCCURRENCES  (CLIMAX  CANTUS-1) 

(APPEND  CANTUS-1  (LIST  (NEXT  NOTE)))) 

--*  [DISTRIBUTE  by  RULE284]  ---> 

(*  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 

( ^OCCURRENCES  (CLIMAX  CANTUS-1)  (LIST  (NEXt  NOTE)))) 

(^OCCURRENCES  (CLIMAX  CANTUS-1)  (LIST  (NEXT  NOTE))) 

---  [ELABORATE  by  RULE124]  —  > 

(0  (SET-OF  XI  (LIST  (NEXT  NOTE))  ('  XI  (CLIMAX  CANTUS-1)))) 

(SET-OF  XI  (LIST  (NEXT  NOTE))  («  XI  (CLIMAX  CANTUS-1))) 

---  [DISTRIBUTE  by  RULE I2l]  — -> 

(UNION  (If  (•  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  (SET  (NEXT  NOTE))  NIL)) 
---  [SIMPLIrY  by  RULE  178]  -*-> 

(IF  (=  (NEXT  NOTE)  (CLIMAX  CANTUS-l))  (SET  (NEXT  NOTE))  NIL) 

(0  (IF  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  (SET  (NEXT  NOTE))  NIL)) 

—  *  [DISTRIBUTE  by  RULE287 ]  — *> 

(If  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(0  (SET  (NEXT  NOTE))) 

(0  NIL)) 

(If  NIL) 

---  [SIMPLIFY  by  RULE2S9]  — -> 

0 

(0  (SET  (NEXT  NOTE))) 

--*  [COMPUTE  by  RULE 283]  ---> 

1 

(•  (♦  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS* 1) 

(If  (-  (NEXT  NOTE)  (CLIMAX  CANTUS-1))  1  0)) 

1) 

---  [DISTRIBUTE  by  RULE237 ]  ---> 

(If  (»  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(»  (♦  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1)  1) 

(-  (♦  ( ^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS‘1)  0)  1)) 

(♦  (^OCCURRENCES  (CLIMAX  CANTUS-t)  CANTUS-1)  0) 

---  [SIMPLIFY  by  RULE343]  — > 


* 
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(•OCCURRENCES  (CLIMAX  CANTUS- l)  CANTUS- 1) 

(»  (♦  (NOCCUR«€NC£S  (CLIMAX  CANTUS-1)  CANTU5-1)  1)  1) 

||  14:2?  ---  (REDUCE  by  RULE290)  — > 

(•  (^OCCURRENCES  (CLIMAX  CANTUS- I)  CANTUS-1)  0) 

||>  14:28  -  [by  AULC208]  ---> 

(CONSIDER  (•  (^OCCURRENCES  (CLIMAX  CANTUS-l)  CANTUS-1)  0)) 

{•OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1) 
t||  14:29  —  [ELABORATE  by  RULE124)  — -> 

(f  (SET-QF  X2  CANTUS- 1  (*  X2  (CLIMAX  CANTUS-1)))) 

(«  (f  (SET -OF  X2  CANTUS-1  (•  X2  (CLIMAX  CANTUS-1))))  0) 

HI  14:30  ---  [RECOGNIZE  by  RULE291) - > 

(NOT  (EXISTS  X2  CANTUS-1  (•  X2  (CLIMAX  CANTUS-1)))) 

(EXISTS  X2  CANTUS- i  (»  X*  (CLIMAX  CANTUS-l))) 

HI  14:31  — -  [RECOGNIZE  by  RULEZ92)  —  > 

(IN  (CLIMAX  CANTUS-l)  CANTUS-l) 

(CLIMAX  CANTUS-t) 

HI  14:32  [ELABORATE  by  RULE124)  — -> 

(HIGHEST  CANTUS-l) 

(IN  (HIGHEST  CANTUS-l)  CANTUS-1) 

HI  14:33  — -  [SIMPLIFY  by  RULE293]  —  > 


(NOT  T) 

III  14:34  ---  [COMPUTE  by  RULE236)  — > 

NIL 

(CONSIDER  NIL) 

||<  14:36  ---  [by  RULE269]  ---> 

(CONSIDER  (IF  (»  (NEXT  NOTE)  (CLTMAX  CANTUS-1)) 

NIL  ("  (•OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1))) 

(IF  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

NIL  (»  (^OCCURRENCES  (CLIMAX  CANTUS-l)  CANTUS-l)  1)) 

||  14:36  [RECOGNIZE  by  RULE294]  — > 

(ANO  [•  (^OCCURRENCES  (CLIMAX  CANT* SI)  CANTUS-1)  1] 

[NOT  (•  (NEXT  NOTE)  (CLIMAX  CANTUS-1)))) 

(CONSIDER  (AND  [»  (•OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  l) 

[NOT  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1))))) 

|<  14  37  ---  [by  RULE 2 69 ]  ---> 

(CONSIDER  (OR  [ANO  [NOT  (CHANGE  (CLIMAX  CANTUS-t))) 

[ANO  [«  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-t)  l) 

[NOT  («  (NEXT  NOTE)  (CLIMAX  CANTUS-l))))) 

[ANO  [CHANGE  (CLIMAX  CANTUS-l)] 

[■  (•OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1))  (NEXT  CANTUS-1))  1)))) 

(ANO  [MOT  (CHANGE  (CLIMAX  CANTUS- I))) 

[ANO  [»  {^OCCURRENCES  (CLIMAX  CANTUS-!)  CANTUS-1)  1) 

[NOT  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1))))) 

|  14:38  ---  [SIMPLIFY  by  RULE  177]  — -> 

(ANO  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-l)  l] 

(NOT  (»  (NEXT  NOTE)  (CLIMAX  CANTUS-l))] 

(NOT  (CHANCE  (CLIMAX  CANTUS-1))]) 

(>  14:39  — -  (by  RULE268]  — -> 

(CONSIDER  (AND  [>  ( •OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[NOT  («  (NEXT  NOTE)  (CLIMAX  CANTUS-1))) 

[NOT  (CHANGE  (CLIMAX  CANTUS-1))))) 

(CHANGE  (CLIMAX  CANTUS-l)) 

||>  14:40  ---  [by  RULE268)  -  — > 

(CONSIDER  (CHANGE  (CLIMAX  CANTUS-1))) 

(CLIMAX  CANTUS-1) 

I))  14:41  --  [ELABORATE  by  RUIE124]  — > 

(HIGHEST  CANTUS-1) 

(CHANGE  (HIGHEST  CANTUS-1)) 

HI  14:42  ---  [REDUCE  by  RULE277]  — > 

(HIGHER  (HIGHEST  (CHANGE  CANTUS-1))  (HIGHEST  CANTUS-1)) 


HI  14:43 


(HIGHEST  CANTUS-t) 

---  (RECOGNIZE  by  RULE123)  — > 
(CLIMAX  CANTUS-l) 
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(CHANGE  CANTUS* 1 ) 

III  14.44  —  [REDUCE  by  RULE279]  — > 

(LIST  (NEXT  NOTE)) 

(HIGHEST  (LIST  (NEXT  NOTE))) 

IU  14:46  —  [SIMPLIFY  by  RULE281]  —  > 

(NEXT  NOTE) 

(CONSIDER  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))) 

||<  14:46  ---  [by  RULE269]  --> 

(CONSIDER  (AND  [»  (^OCCURRENCES  (CLIMAX  CAHTUS-l )  CAHTVS-t)  1] 

[NOT  (*  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]. 

[MOT  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))])) 

(AND  [»  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-l)  1] 

(NOT  (*  (NEXT  NOTE)  (CLIMAX  CANTUS-l))] 

(NOT  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))]) 

(|  14:47  ---  (COLLECT  by  RULE296]  — -> 

(AND  f*  (#OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  l] 

[NOT  (OR  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS'l)] 

[*  (NEXT  NOTE)  (CLIMAX  CANTUS-1)])]) 

(OR  [HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-l)] 

[»  (NEXT  MOTE)  (CLIMAX  CANTUS'l)]) 

||  14:48  ---  [COLLECT  by  RULE297]  ---> 

((OR  HIGHER  «)  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(NOT  ((OR  HIGHER  -)  (NEXT  NOTE)  (CLIMAX  CANTUS-1))) 

)|  14:49  ---  [by  RULE 298]  ---> 

({NOT  (OR  HIGHER  »))  (NEXT  NOTE)  (CLIMAX  CANTUS-1)) 

(NOT  (OR  HIGHER  »)) 

||  14:50  —  [RECOGNIZE  by  RULE 299 ]  — -> 

LOWER 

(CONSIDER  'AND  [•  (AOCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  l] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)])) 

|<  14:51  —  [by  RULE269]  — -> 

(COMSIOER  (OR  [AND  [»  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-l)  l] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS'l)]] 

[AND  [CHANGE  (CLIMAX  CANTUS-1)) 

(»  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS- 1))  (NEXT  CANTUS-1))  1]])) 

(ANO  [CHANGE  (CLIMAX  CANTUS-l)] 

£•  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-l))  (NEXT  CANTUS- 1))  l]) 

|>  14.52  ---  [by  RULE268]  ---> 

(CONSIDER  (AND  [CHANGE  (CLIMAX  CANTUS-1)] 

[*  (^OCCURRENCES  (NEXT  (CLIMAX  CANTUS-1))  (NEXT  CANTUS-1))  l])) 

(CLIMAX  CANTUS" 1 ) 

||  14:63  ---  [ELABORATE  by  RULE124]  ---> 

(HIGHEST  CANTUS-1) 

(CHANGE  (CLIMAX  CANTUS-1)) 

||  14:64  — -  [REDUCE  by  RUIE301 ]  — > 

(HIGHER  (HIGHEST  (CHANGE  CANTUS-l))  (HIGHEST  CANTUS-l)) 

(NEXT  (HIGHEST  CANTUS- t)) 

1 | >  14:56  ---  [REDUCE  by  RULE300]  — -> 

(SHOW  (HIGHER  (HIGHEST  (CHANGE  CANTUS-l))  (HIGHEST  CANTUS-1))) 

(HIGHER  (HIGHEST  (CHANGE  CANTUS-1))  (HIGHEST  CANTUS-1)) 
HI  14:58  ---  [EVAL  by  RULE302]  ---> 


(SHOW  T) 

||<  14:67  ---  (SUCCEED  by  RULE34]  ---> 

(CONSIDER  (ANO  (HIGHER  (HIGHEST  (CHANGE  CANTUS-1))  (HIGHEST  CANTUS-1)] 

(«  (^OCCURRENCES  (HIGHEST  (CHANGE  CANTUS-1))  (NEXT  CANTUS-1))  t])) 

(CHANGE  CANTUS-1) 

||  14:58  ---  [REOUCE  by  RULE279]  ---> 

(LIST  (NEXT  NOTE)) 

(HIGHEST  (LIST  (NEXT  NOTE))) 

||  14:69  ---  [SIMPLIFY  by  RULE281]  — > 

(NEXT  NOTE) 


(f  14:60 


(HIGHEST  (CHANGE  CANTUS-1)) 
—  -  (REDUCE  by  RULE 301]  — > 
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|  14:61 

|  14:62 

|  14:63 

|  14:64 

|  14:66 

|  14:66 

|  14:67 

|  14:66 

|  14:69 

|  14:70 

J  14:71 

|  14:72 

|>  14:73 

ill  14:74 

III  14:75 

||<  14:76 

II 

II  14:76 

||  14:79 

|<  14:80 


(NEXT  NOTE) 

(NEXT  CANTUS- 1) 

---  (REDUCE  by  RULE301]  — -> 

(APPENO  CANTUS- 1  (LIST  (NEXT  NOTE))) 

(•OCCURRENCES  (NEXT  NOTE)  (APPEND  CANTUS- 1  (LIST  (NEXT  NOTE)))) 

---  [DISTRIBUTE  by  RULE284]  --> 

(♦  (^OCCURRENCES  (NEXT  NOTE)  CANTUS-l) 

( ^OCCURRENCES  (NEXT  NOTE)  (LIST  (NEXT  NOTE)))) 

(•OCCURRENCES  (NEXT  NOTE)  (LIST  (NEXT  NOTE))) 

---  [ELABORATE  by  RULE  124]  — > 

(4  (SET-OF  X4  (LIST  (NEXT  NOTE))  (>  X4  (NEXT  NOTE)))) 

(SET-OF  X4  (LIST  (NEXT  NOTE))  (•  X4  (NEXT  NOTE))) 

---  [DISTRIBUTE  by  RULE121]  — > 

(UNION  (IF  («  (NEXT  NOTE)  (NEXT  NOTE))  (SET  (NEXT  NOTE))  NIL)) 
---  [SIMPLIFY  by  RULE178]  — > 

(IF  (-  (NEXT  NOTE)  (NEXT  NOTE))  (SET  (NEXT  NOTE))  NIL) 

(•  (NEXT  NOTE)  (NEXT  NOTE)) 

—  -  [EVAL  by  RULE  179]  *--> 


(IF  T  (SET  (NEXT  NOTE))  NIL) 

—  [SIMPLIFY  by  RULE  186]  — -> 

(SET  (NEXT  NOTE)) 

(4  (SET  (NEXT  NOTE))) 

---  [COMPUTE  by  RULE 288]  — > 

1 

(«  (♦  (40CCURRENCES  (NEXT  NOTE)  CANTUS-l)  1)  1) 

---  [REDUCE  by  RULE290]  —  > 

(»  (40CCURRENCES  (NEXT  NOTE)  CANTUS-l)  0) 

(•OCCURRENCES  (NEXT  NOTE)  CANTUS-l) 

---  (ELABORATE  by  RULE  124]  — *> 

(4  (SET-OF  X5  CANTUS-l  (•  X5  (NEXT  NOTE)))) 

(*  (#  (SET-Of  X5  CANTUS-l  (•  X5  (NEXT  NOTE))))  0) 
---  [RECOGNIZE  by  RULE291]  — > 

(NOT  (EXISTS  X5  CANTUS-l  (-  X6  (NEXT  NOTE)))) 

(EXISTS  X5  CANTUS-l  (-  X5  (NEXT  NOTE))) 

---  [RECOGNIZE  by  RULE292]  — > 

(IN  (NEXT  NOTE)  CANTUS-l) 

---  [REDUCE  by  RULE304]  ---> 

(SHOW  (NOT  (HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-l)))) 

(HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-l)) 
---  [EVAL  by  RULE302]  — -> 

T 

(NOT  T) 

— -  [COMPUTE  by  RULE238]  ---> 

NIL 

(SHOW  NIL) 

---  [SUCCEEO  by  RULE52]  --> 

(CONSIDER  (ANO  (HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-l)]  [NOT  NIL])) 
(NOT  NIL) 

---  [COMPUTE  by  RULE236]  — > 

T 

(AND  [HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-l)]  T) 

— -  [SIMPLIFY  by  RULE343]  — > 

(HIGHER  (NEXT  NOTE)  (HIGHEST  CANTUS-l)) 

(HIGHEST  CANTUS-l) 

---  [RECOGNIZE  by  RULE123]  — > 

(CLIMAX  CANTUS-l) 

(CONSIDER  (HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-l))) 

---  [by  RULE 2 69]  — -> 

(CONSIDER  (OR  [ANO  (•  ( 40CCURRENCES  (CLIMAX  CANTUS-l)  CANTUS-l)  l] 
[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-l)]] 
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[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS- 1)])) 

(CONSIOER  (OR  [ANO  [•  (NOCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-t)  1} 

[LOWER  (NEXT  MOTE)  (CLIMAX  CANTUS-1)]] 

(HI6HER  (MEXT  MOTE)  (CLIMAX  CANTUS-!)])) 

<  14 : Al  ---  [by  RULE269]  — -> 

(FORALL  Tl  ( LB : U6  0  (-  (*  CANTUS)  1)) 

((OR  [ANO  [>  (fOCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-i)]] 

[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

Tl)) 

((OR  [AMD  [■  (^OCCURRENCES  (CLIMAX  CANTUS-1)  CANTUS-1)  1] 

[LOWER  (NEXT  NOTE)  (CLIMAX  CANTUS-1))] 

[HIGHER  (NEXT  NOTE)  (CLIMAX  CANTUS-1)]) 

Tl) 

14:82  — -  [REDUCE  by  RULE273]  — -> 

(OR  [ANO  [■  (^OCCURRENCES  (CLIMAX  (CANTUS-1  Tl))  (CANTUS-1  Tl))  1] 
[LOWER  (MEXT  (NOTE  Tl))  (CLIMAX  (CANTUS-1  Tl))]] 

[HIGHER  (MEXT  (NOTE  Tl))  (CLIMAX  (CANTUS-1  Tl))]) 

(NEXT  (NOTE  Tl)) 

>  14:83  — -  [by  RULE288]  — > 

(CONSIDER  (NEXT  (NOTE  Tl))) 

(NEXT  (NOTE  Tl)) 

|  14:84  — -  [COLLECT  by  RULE305]  — > 

((NEXT  MOTE)  Tl) 

(NEXT  NOTE) 

1  14:86  (ELABORATE  by  RULE124]  ---> 

(LAMBDA  (J)  (NOTE  (♦  J  1))) 

((LAMBDA  (J)  (NOTE  (♦  J  l)))  Tl) 

|  11:86  ---  (SIMPLIFY  by  RULE213]  ---> 

(NOTE  (♦  Tl  1)) 

(CONSIOER  (NOTE  (♦  Tl  1))) 

<  14:87  ---  [by  RULE 269]  — > 

(FORALL  Tl  (LBUB  0  (-  (A  CANTUS)  1)) 

(OR  [AND  (*  (AOCCURRENCES  (CLIMAX  (CANTUS-1  Tl))  (CANTUS-1  Tl))  1] 
[LOWER  (NOTE  (♦  Tl  l))  (CLIMAX  (CANTUS-l  Tl))]] 

[HIGHER  (More  (♦  ri  !|J  (CLIMAX  (CAMTVS-l  Tl))))) 

[Final  oxprtss ion : ] 

(FORALL  Tl  (LBUB  0  (-  (f  CANTUS)  1)) 

(OR  (ANO  [*  (^OCCURRENCES  (CLIMAX  (CANTUS-1  Tl))  (CANTUS-1  Tl))  1] 
[LOWER  (NOTE  (♦  Tl  l))  (CLIMAX  ICANTUS-l  Tl))]] 

[HIGHER  (NOTE  (♦  Tl  l))  (CLIMAX  (CANTUS-1  Tl))])) 

NIL  rtcordrti* 

RECORO  FILE  OSK:  (D14007  P2G)  CLOSCO  07-DEC-80  19:51:18 
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Appendix  E 
Operationality 


This  appendix  shows  the  result  of  applying  a  simple  recursive  procedure  for  analyzing  the 
operationality  of  an  expression.  For  each  solution  derived  using  FOO,  the  procedure  identifies  a  set  of 
conditions  under  which  it  is  operational. 


RECORD  FILE  DSK:  (0PE319  .  QZG )  OPENEO  20-MAR-81  18:45:10 
MIL 

<92>for-each  d  derivations  (p-o  d) 

0ERIV2 

(ACHIEVE  (MOT  HSM1 ) ) 

Is  operational  if 

NOT  is  ACHIEVABLE 

specifically  (MOT  HSM1)  Is  OOABLE 
HSM1  Is  KNOWN 


is  operational  if 

POSSIBLE  is  COMPUTABLE 

specifically  (POSSIBLE  (LEGAL  PI  C2))  is  EVALUABLE 
LEGAL  is  COMPUTABLE 

specifically  (LEGAL  PI  C2)  is  EVALUABLE 
CARDS-PLAYEOl  is  KNOWN 

specifically  (CAR0S-PLAYE01  ME)  is  EVALUABLE 
MY-CARD4  Is  KNOWN 

specifically  (MY-CARD4  :  (CARO-OF  ME))  is  EVALUABLE 
SUIT-LE02  is  KNOWN 

specifically  (SUIT-LE02  :  (SUIT-LED) )  is  EVALUABLE 
CAR0S-PLAYE01  is  COMPUTABLE 

specifically  (CAROS-PLAYEDl  ME)  is  EVALUABLE 
(CARO-OF  (LEADER))  is  EVALUABLE 

(PROJECT  CARO-OF  (PREFIX  (PLAYERS)  ME))  is  EVALUABLE 


0ERIV3 

(UNTIL  (PLAYED!  QS)  (ACHIEVE  (LEAD-SPADE  ME))) 

is  operational  If 

LEAO-SPAOE  is  ACHIEVABLE 

specifically  ( LFAO-SPAOE  ME)  is  OOABLE 


0ERIV4 

(EVAL  (NOT  (OR  [IN-POT  QS]  [AT  QS  HOLE]  [HAS-ME  QS]  [TAKEN  QS]))) 

is  operational  if 

(AT  QS  HOLE)  is  EVALUABLE 
TAKE  is  OBSERVABLE 


DERIVE 
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(UNTIL  (PLAYEO!  QS )  (ACHIEVE  (LEAD-SAFE -SPADE  ME))) 

1$  operational  If 

LEAD-SAFE -SPADE  Is  ACHIEVABLE 

specifically  ( LEAD-SAFE -SPAOE  ME)  Is  OOA8LE 


DERIV6 

(ACHIEVE  (•>  (AND  [IN-SUIT-LED  (CARO-OF  ME)]  [TRICK-HAS-POINTS] ) 
(LOW  (CARO-OF  ME)))) 

Is  operational  If 

(CARD-OF  (LEADER))  Is  EVALUABLE 
(HAVE-POINTS  (CARDS-PLAYED))  Is  EVALUABLE 

(ACHIEVE  (■>  (AND  [IN-SUIT-LEO  (CARO-OF  ME)]  [TRICK-HAS-POINTS]) 
(LOWER  (CARO-OF  ME)  OK))) 


Is  operational  If 

(CARO-OF  (LEADER))  Is  EVALUABLE 
(HAVE-POINTS  (CARDS-PLAYED))  Is  EVALUABLE 


DERIV7 

(ACHIEVE  (AND  [IN-SUIT-LED  (CARD-OF  ME)]  [HIGH  (CARO-OF  ME)])} 

Is  operational  If 

(CARO-OF  (LEADER))  Is  EVALUABLE 


OERIVS 

(UNTIL  (VOIO  ME  SO)  (ACHIEVE  (PLAY-SUIT  ME  SO))) 

Is  operational  If 

(VOID  ME  SO)  Is  EVALUABLE 
SO  Is  KNOWN 

PLAY-SUIT  Is  ACHIEVABLE 

specifically  (PLAY-SUIT  ME  SO)  Is  DOABLE 


DERIV9 

( FUNCTION-OF  (NCARDS-OUT-IN-SUIT  SO)  DECREASING) 

Is  operational  If 

SO  is  KNOWN 
OUT  is  COMPUTABLE 


OERIVIO 
(EVAL  (-  (-  13 

(*  (SET-OF  XI  (CARDS- IN-SUIT  SO) 

(BEFORE  (CURRENT  ROUND-IN-PROGRESS)  (HAS  ME  XI))))) 

(0  (SET-OF  XI  (CAROS-IN-SUIT  SO) 

(WAS-DURING  (CURRENT  ROUNO-IN-PROGRESS) 

(EXISTS  P3  (OPPONENTS  ME)  (PLAY  P3  XI))))))) 


Is  operational  If 

(SET-OF  XI  (CAROS-IN-SUIT  SO)  (BEFORE  (CURRENT  ROUNO-IN-PROGRESS)  (HAS  ME  XI)) 

SO  Is  KNOWN 

PLAY  is  OBSERVABLE 

specifically  (PLAY  P3  XI)  Is  Of TFCTABLE 


DER1V11 

(EVAL  (AND  [BREAKING-SUIT  PO]  [•  (SUIT-LED)  SO]  [FOLLOWING  PO ] ) ) 

is  operational  If 

(CARD-OF  PO)  Is  EVALUABLE 
PO  Is  KNOWN 

(CARO-OF  ( LEADER ) )  Is  EVALUABLE 
SO  Is  KNOWN 


)  Is  EVALUABLE 
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DERIV12 

(EVAL  (WAS  DURING  (CURRENT  ROUNO-IN-PROGRESS)  (VOIO  PO  SO))) 

Is  operational  if 

VOID  is  OBSERVABLE 

specifically  (VOIO  PO  SO)  Is  DETECTABLE 
PO  Is  KNOWN 
SO  Is  KNOWN 


DERIV13 
(ACHIEVE  HSM1) 

Is  operational  If 

HSM1  is  EVALUABLE 


is  operational  if 

PROJECT1  is  COMPUTABLE 

specifically  (PROJECT1  (-  II  1))  Is  EVALUABLE 
CANTUS-LENGTH  Is  COMPUTABLE 

specifically  (CANTUS-LENGTH)  Is  EVALUABLE 
CL I MAXI  is  KNOWN 
PROJECT1  is  KNOWN 

specifically  (PROJECTl  (-  II  1))  Is  EVALUABLE 


OERIV14 

(FORALL  n  (L8:UB  0  (-  (*  CANTUS)  1)) 

(OR  [AND  [-  (^OCCURRENCES  (CLIMAX  (CANTUS'l  Tl) ) 
(CANTUS-l  Tl))  1] 

[LOWER  (NOTE  (r  Tl  1))  (CLIMAX  (CANTUS-l  Tl))]] 
[HIGHER  (NOTE  (r  Tl  1))  (CLIMAX  (CANTUS-l  Tl))])) 

Is  operational  if 

(N  CANTUS)  Is  EVALUABLE 
CLIMAX  is  COMPUTABLE 

specif  leal ’y  (CLIMAX  (CANTUS-l  Tl))  Is  EVALUABLE 
CANTUS-l  Is  COMPUTABLE 

specifically  (CANTUS-l  Tl)  Is  EVALUABLE 
NOTE  is  COMPUTABLE 

specifically  (NOTE  (♦  Tl  1))  is  EVALUABLE 


NIL 

<93>recordf 1 le 

RECORD  FILE  OSK:  (OPE319  .  QIG)  CLOSED  ZO-MAR-81  18:47:10 


478 


§E.  Operationality 


< 


For  real  die-hards,  here  is  the  procedure: 


RECORO  FILE  OSK:  (OPE322  .  QZG)  OPENED  22-MAR-B1  23:07:22 
NIL 

<33>pp  p-0 
(DE  P-0  (N) 

(•••  ANALYZE  OPERATIONALITY  OF  N) 

(COND  [  ( N  1  N)  (P-0  (E<N  N))] 

[(OERIVI  N) 

(NSG  T  N) 

(MAPCAR  (FUNCTION  P-0)  (GET  N  FINAL-EXPRESSIONS))] 

[(PROG  (PL  CRITERION  VARIABLES  FNS-STACK) 

(SETQ  PL  ( E >0  N)) 

(••*  (SPRINT  PL  l)) 

(IF  (NEQ  (CAOfi  N)  WITH)  (SPRINT  N  l)) 

(NSG  T  T  "Is  operational”) 

(IF  PL  (NSG."  If")) 

(FOR-EACH  PAIR  (S£T<LIST  PL) 

(MSG  T  8  (CAOR  PAIR)  "  Is  *  (CAR  PAIR)) 

(FOR-EACH  £  (Et<FN  N  (CAOR  PAIR)) 

(MSG  T  16  "specifically  ”  E  '  Is  " 
(SELECTQ  [CAR  PAIR] 

[COMPUTABLE  ’EVALUABLE] 
[VISIBLE  OBSERVABLE] 
[OBSERVABLE  DETECTABLE] 
[ACHIEVABLE  DOABLE] 
’EVALUABLE)))) 

(MSG  T  T))]) 

») 

NIL 

<34>recordf lie 

RECORO  FILE  OSK:  (OPE322  .  QZG)  CLOSEO  22-MAR-Bt  23:07:46 


« 


« 
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